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

On Wed, 4 Oct 2023 at 10:17, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:

> On 31.07.23 18:27, Dave Cramer wrote:
> > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson <daniel(at)yesql(dot)se
> > <mailto:daniel(at)yesql(dot)se>> wrote:
> >
> > > On 25 Apr 2023, at 16:47, Dave Cramer <davecramer(at)gmail(dot)com
> > <mailto:davecramer(at)gmail(dot)com>> wrote:
> >
> > > Patch attached with comments removed
> >
> > This patch no longer applies, please submit a rebased version on top
> > of HEAD.
> >
> >
> > Rebased see attached
>
> I have studied this thread now. It seems it has gone through the same
> progression with the same (non-)result as my original patch on the subject.
>
> I have a few intermediate conclusions:
>
> - Doing it with a GUC is challenging. It's questionable layering to
> have the GUC system control protocol behavior. It would allow weird
> behavior where a GUC set, maybe for a user or a database, would confuse,
> say, psql or pg_dump. We probably should make some of those more robust
> in any case. Also, handling of GUCs through connection poolers is a
> challenge. It does work, but it's more like opt-in, and so can't be
> fully relied on for protocol correctness.
>
> - Doing it with a session-level protocol-level setting is challenging.
> We currently don't have that kind of thing. It's not clear how
> connection poolers would/should handle it. Someone would have to work
> all this out before this could be used.
>
> - In either case, there are issues like what if there is a connection
> pooler and types have different OIDs in different databases. (Or,
> similarly, an extension is upgraded during the lifetime of a session and
> a type's OID changes.) Also, maybe, what if types are in different
> schemas on different databases.
>
> - We could avoid some of the session-state issues by doing this per
> request, like extending the Bind message somehow by appending the list
> of types to be sent in binary. But the JDBC driver currently lists 24
> types for which it supports binary, so that would require adding 24*4=96
> bytes per request, which seems untenable.
>
> I think intuitively, this facility ought to work like client_encoding.
> There, the client declares its capabilities, and the server has to
> format the output according to the client's capabilities. That works,
> and it also works through connection poolers. (It is a GUC.) If we can
> model it like that as closely as possible, then we have a chance of
> getting it working reliably. Notably, the value space for
> client_encoding is a globally known fixed list of strings. We need to
> figure out what is the right way to globally identify types, like either
> by fully-qualified name, by base name, some combination, how does it
> work with extensions, or do we need a new mechanism like UUIDs. I think
> that is something we need to work out, no matter which protocol
> mechanism we end up using.
>

So how is this different than the GUC that I proposed ?

Dave