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

On Tue, Mar 21, 2023 at 4:47 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> On Tue, 2023-03-21 at 09:22 -0400, Dave Cramer wrote:
> > As Jeff mentioned there is a visibility problem if the search path is
> > changed. The simplest solution IMO is to look up the OID at the time
> > the format is requested and use the OID going forward to format the
> > output as binary. If the search path changes and a type with the same
> > name is now first in the search path then the data would be returned
> > in text.
>
> Am I over-thinking this?
>

I think so. Dave's idea puts a lot of flexibility into the client
side, and that's good. Search path mechanics are really well understood
and well integrated with extensions already (create extension ..schema)
assuming that the precise time UDT are looked up in an unqualified way is
very clear to- or invoked via- the client code. I'll say it again though;
OIDs really ought to be considered a transient cache of type information
rather than a permanent identifier.

Regarding UDT, lots of common and useful scenarios (containers, enum,
range, etc), do not require special knowledge to parse beyond the kind of
type it is. Automatic type creation from tables is one of the most
genius things about postgres and directly wiring client structures to them
through binary is really nifty. This undermines the case that binary
parsing requires special knowledge IMO, UDT might in fact be the main long
term target...I could see scenarios where java classes might be glued
directly to postgres tables by the driver...this would be a lot more
efficient than using json which is how everyone does it today. Then again,
maybe *I* might be overthinking this.

merlin