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

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

> Jeff Davis <pgsql(at)j-davis(dot)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

Dave