Unable to use BeginBinaryImport on table with a custom composite type

Steps to reproduce

We have a table defined as follows:

CREATE TYPE my_custom_type AS (f1 int, f2 text);

CREATE TABLE aTable
(
    id serial primary key,
    custom_col my_custom_type
)

Running the following BeginBinaryImport results in an error message:

using (var writer = conn.BeginBinaryImport($"COPY \"public\".\"aTable\" (\"id\",\"custom_col\") FROM STDIN (FORMAT BINARY)"))
{
    writer.StartRow();
    writer.Write(1,"integer")
    writer.Write([composite value], "text")
    writer.Complete();
}

where [composite value] represents whatever I’m trying to insert for the composite value. I’ve tried formatting the value in many different ways such as:

'(1,"asdf")'
(1,"asdf")
ROW(1,"asdf")

This fails with the stack trace:

System.AggregateException: One or more errors occurred. (One or more errors occurred. (42804: wrong number of columns: 656956450, expected 1)) —> System.AggregateException: One or more errors occurred. (42804: wrong number of columns: 656956450, expected 1) —> Npgsql.PostgresException (0x80004005): 42804: wrong number of columns: 656956450, expected 1 at Npgsql.NpgsqlConnector.<ReadMessage>g__ReadMessageLong|202_0(NpgsqlConnector connector, Boolean async, DataRowLoadingMode dataRowLoadingMode, Boolean readingNotifications, Boolean isReadingPrependedMessage) at Npgsql.NpgsqlBinaryImporter.Complete(Boolean async, CancellationToken cancellationToken) at Npgsql.NpgsqlBinaryImporter.Complete()

Further technical details

Npgsql version: 5.0 PostgreSQL version: 9.6 Operating system: Windows

Other details about my project setup:

[akamor]

And btw, in case we never talk again I should at least thank you and all of the other maintainers for creating/supporting such a great product. We all really appreciate it!

[akamor]

Thanks for your help.

And yes, we represent the composite type as text when we first grab it from the users database by doing a type coercion to text, e.g. select id, custom_col::text from aTable;

At least this is our current plan and is working OK in our initial tests.

Interestingly, we do this for a few other types as well such as numeric and decimal as the CLR equivalent types don’t support the full range of values that Postgres supports.