Jeff Davis <pgsql@j-davis.com> writes: > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote: >> Most of the clients know how to decode the builtin types. I'm not >> sure there is a use case for binary encode types that the clients >> don't have a priori knowledge of.
> The client could, in theory, have a priori knowledge of a non-builtin > type.
I don't see what's "in theory" about that. There seems plenty of use for binary I/O of, say, PostGIS types. Even for built-in types, do we really want to encourage people to hard-wire their OIDs into applications?
How does a client read these? I'm pretty narrowly focussed. The JDBC API doesn't really have a way to read a non built-in type. There is a facility to read a UDT, but the user would have to provide that transcoder. I guess I'm curious how other clients read binary UDT's ?
I don't see a big problem with driving this off a GUC, but I think it should be a list of type names not OIDs. We already have plenty of precedent for dealing with that sort of thing; see search_path for the canonical example. IIRC, there's similar caching logic for temp_tablespaces.
I have no issue with allowing names, OID's were compact, but we could easily support both
Attached is a preliminary patch that takes a list of OID's. I'd like to know if this is going in the right direction.
Next step would be to deal with type names as opposed to OID's.
This will be a bit more challenging as type names are schema specific.
