search

isoos / postgresql-dart

Dart PostgreSQL driver: supports extended query format, binary protocol and statement reuse.
https://pub.dev/packages/postgres
BSD 3-Clause "New" or "Revised" License
131 stars 37 forks source link

TypeCodec #349

Closed isoos closed 3 months ago

isoos commented 3 months ago

/cc @simolus3: This PR and #348 is a work towards #346 (and extensibility in general). The current PR has TypeCodec separately from Type, but in the end I see little to no benefit separating them: the encode and decode methods may live on the Type object, so next iteration would be just Type with the two extra methods. I also think that the current encode/decode method signatures may be stable (with the context being extensible). Any comments on the design or insight wrt. package:drift compatibility?

simolus3 commented 3 months ago

Drift doesn't use the TypeCodec directly, so as long as we're still able to specify the types to use for parameters, that doesn't cause any incompatibilities.

but in the end I see little to no benefit separating them: the encode and decode methods may live on the Type object, so next iteration would be just Type with the two extra methods

IIRC we had that distinction in the v2 API and I've carried that over to the initial v3 implementation so that it doesn't have to be part of the public API (which types are). But now since that appears to stand in the way of supporting more complex types / OID caches, I agree that just moving that functionality to Type directly makes sense.

isoos commented 3 months ago

IIRC we had that distinction in the v2 API and I've carried that over to the initial v3 implementation so that it doesn't have to be part of the public API (which types are). But now since that appears to stand in the way of supporting more complex types / OID caches, I agree that just moving that functionality to Type directly makes sense.

I'm a bit undecided on this. It would make sense to move the method to the Type class. As an alternative, we could migrate the Type to be an extension type on int (meaning it is just the OID value, while we keep the current methods), while the codec methods (including the custom type methods) remain separate (and the TypeRegistry may take them as a constructor parameter (e.g. Map<int, TypeCodec>)

isoos commented 3 months ago

The more I think of it, the more I'm for separating the Type from the two methods. It keeps more options open: