Unmapped composite types removal

[fuyfuy]

Hello everyone!
We're using npgsql for a big project and wanted to upgdate to version 5. However we noticed that support for unmapped composite types was removed.
We rely pretty heavily on ExpandoObject to pass unmapped TVP to the database. We wonder why the support was removed and how complicated would it be to bring ExpandoObject support back in V5?

[YohDeadfall]

Could you explain why do you prefer ExpandoObject to strongly typed types?

Unmapped composite support was dropped because of it's reflection usage which is slow, inefficient and error prone. Ideally we should support generators as an addition for strongly typed composite handling.

[fuyfuy]

Hi @YohDeadfall, thanks for the quick answer.
A bit of background on how we use TVPs and ExpandoObject:
We do prefer strongly typed types in most cases. One place we're using dynamic types is an ETL workflow that imports data to a few hundred tables (essentially a custom database synchronization). Originally it was targetting SQL Server, which doesn't require CLR types for TVPs to work. When we added Postgres support, we used ExpandoObject to avoid creating and maintaining hundreds of (often changed) CLR types which are only used in a single place in the code.

[YohDeadfall]

Just for now you can take the code of unmapped composite handler and register it for all PostgreSQL composite types except that covered by strongly typed handler. That will work.

Need to think about bringing it back since I would like to redesign type handling and finish it for 6.0.

When we added Postgres support, we used ExpandoObject to avoid creating and maintaining hundreds of (often changed) CLR types which are only used in a single place in the code.

Records from C# 9 should help in that case because it's easy to write them and the driver supports constructors, as maintainers of a large project it will also bring safety to your code.

[roji]

Putting this in the backlog for now.

[NinoFloris]

@roji what is specifically in the backlog here?

We could add support for reading unmapped composites as Dictionary<string, object> ... I don't think we'd want to support ExpandoObject again?

[NinoFloris]

Unmapped composites can be read via nested readers via reader.GetData(). The remaining work for writing is tracked in #5415