[Question] Are composite types defined in PostgreSQL supported by SQLProvider?

Start with PostgreSQLTests.fsx and trace how SQLProvider discovers and represents stored-procedure parameters. Compare the reported composite-type signature with the existing PostgreSQL type examples and the Npgsql workaround. Done means establishing whether composite types are supported and documenting or testing the required mapping or limitation.

Description

Database has composite types defined which are input/output types to stored procedures. I am attempting to call the said procedure with input parameters. SqlProvider does not see the input parameter and assumes it is a void function.

Repro steps

The composite type defined in the database is

CREATE TYPE product_t AS
   (name text,
    product_type text)

The signature of procedure in the database is

create or replace function func_iproduct( p product_t ) returns void as

On .NET side (F#), I have created a type

type PgProductType(Name:string,ProductType:string)=
  member this.Name = Name 
  member this.ProductType = ProductType
  new() = PgProductType("","")

I believe there should be a way in which I could tell SqlProvider how to map PgProductType to product_t; not sure if this is required or such mapping is automatic. If required, an example how do I go about doing it would be helpful. Without this mapping, if I attempt to execute the procedure, the error message it reports back indicates that SqlProvider does NOT see the input parameter;

let prd = new PgProductType("F#Product","")
ctx.Functions.FuncIproduct.Invoke(prd)

stdin(29,1): error FS0501: The member or object constructor 'Invoke' takes 0 argument(s) but is here given 1. The required signature is 'SqlDataProvider<...>.dataContext.Functions.FuncIproduct.Result.Invoke() : Unit'.

Question

1. Can I use postgresql composite types? If so, an illustrative example would help.The test suite PostgreSQLTests.fsx does not contain an example to map custom types (though there are examples to map pre-defined postgresql types).
2. Any alternative solution short of re-implementing queries (using query expressions) foregoing the existing procedures?

Known workarounds

Directly use Npgsql

Related information

• PostgreSQL 9.6
• Win 7