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.
OIDs are a pain to deal with IMO. They will not survive a dump style restore, and are hard to keep synchronized between databases...type names don't have this problem. OIDs are an implementation artifact that ought not need any extra dependency.
AFAIK, OID's for built-in types don't change.
Clearly we need more thought on how to deal with UDT's
This seems like a protocol or even a driver issue rather than a GUC issue. Why does the server need to care what format the client might want to prefer on a query by query basis?
Actually this isn't a query by query basis. The point of this is that the client wants all the results for given OID's in binary.
I just don't see it. The resultformat switch in libpq works pretty well, except that it's "all in" on getting data from the server, with the dead simple workaround of casting to text which might even be able to be managed from within the driver itself.
