Repository: npgsql/npgsql

Issue #1746: Support unmapped composites as dynamic
Created: 2017-12-13T03:41:39Z
Npgsql currently supports unmapped enums as simple strings. This removes the need to define a CLR enum and can help in some dynamic scenarios where the database schema isn't known ahead of time.
Try to implement the same for composite types, reading and writing them as type dynamic.
The main blocker here is that unlike all other types, composite definitions are loaded lazily by Npgsql, rather than at first-connection-time. This was done since a composite type is created for each table, leading to a quick explosion of composite types and an unreasonable start time (see #1126). However, it's easy to distinguish real composite types from table types by joining the pg_type entry with pg_class and checking relkind (see https://www.postgresql.org/docs/current/static/catalog-pg-class.html). So we could switch back to eager loading for composites and then return dynamic.
The only casualty here would be mapping tables as composite types (#990), since we'd stop loading type definitions for those. We could leave lazy/late type loading just for this case, but it a little too rare/exotic and it seems better to simplify Npgsql to be eager-loading only.
Inspired by #1736.

Duplicate issue #1696: Getting parameter types for a query
Created: 2017-10-30T18:01:17Z
I'm looking to build F# type provider for PostgreSQL EF Core.
I would love to support both direct tables + LINQ and Raw SQL queries for non-Model types.
To support Raw Sql raw queries in reasonable way information about parameter types is necessary.
For example for query
SELECT table_schema, table_name 
FROM information_schema.tables 
WHERE table_type = @table_type AND @x > 42;
or
SELECT table_schema, table_name 
FROM information_schema.tables 
WHERE table_type = :table_type AND :x > 42;
somehow I need to figure out that type of table_type is .NET String and x is .NET Int32.
My understanding that PostgreSQL can provide this information for positional parameters e.g.
PREPARE my_query AS
SELECT table_schema, table_name FROM information_schema.tables WHERE table_type = $1 AND $2 > 42;
SELECT parameter_types FROM pg_prepared_statements WHERE name = 'my_query';
DEALLOCATE my_query; 
Which return {text,integer}.
A challenge is to go from nicely named parameters supported by this library to positional only supported by PostreSQL engine itself.
Ideally scenario of inferring unbound parameter types would be supported directly by the library API either via Npgsql​Command​Builder.DeriveParameters or Npgsql​Command.Prepare. As of now, the first only supports functions and second requires all parameters specified upfront.
If request above is unacceptable or too much work then the other option is to change functionality of
https://github.com/npgsql/npgsql/blob/dev/src/Npgsql/SqlQueryParser.cs private class. Specifically method ParseRawQuery needs to be able to replace named parameters by positional but retain order for particular statement so it can be mapped back.   
  
    
      npgsql/src/Npgsql/SqlQueryParser.cs
    
    
         Line 51
      in
      b36403a
    
  
  
    

        
          
           internal void ParseRawQuery(string sql, bool standardConformantStrings, NpgsqlParameterCollection parameters, List<NpgsqlStatement> statements) 
        
    
  


Although not ideal I'm fine with accessing it via reflection. It's still better option than rolling out my own named parameters parsing logic.

Closing comment (2018-03-18T14:12:22Z): I think so, yes.
In the current state, not everything that we derive really works in queries (actually only arrays of unmapped composite types come to mind) but still derivation should work as intended and the missing functionality is tracked in #1746 (and loosely related #1842 )