Re: Request for comment on setting binary format output per session

Dave Cramer

On Sat, 4 Mar 2023 at 19:39, Dave Cramer <davecramer@gmail.com> wrote:

On Sat, 4 Mar 2023 at 19:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:

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.