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

Dave Cramer

On Sat, 25 Mar 2023 at 19:06, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> On Thu, 2023-03-23 at 15:37 -0400, Dave Cramer wrote:
> > So where do we go from here ?
> >
> > I can implement using type names as well as OID's
>
> My current thought is that you should use the protocol extension and
> make type names work (in addition to OIDs) at least for fully-qualified
> type names. I don't really like the GUC -- perhaps I could be convinced
> it's OK, but until we find a problem with protocol extensions, it looks
> like a protocol extension is the way to go here.
>
> Well as I said if I use any external pool that shares connections with
multiple clients, some of which may not know how to decode binary data then
we have to have a way to set the binary format after the connection is
established. I did float the idea of using the cancel key as a unique
identifier that passed with the parameter would allow setting the parameter
after connection establishmen.

I like Peter's idea for some kind of global identifier, but we can do
> that independently at a later time.
>
> If search path works fine and we're all happy with it, we could also
> support unqualified type names. It feels slightly off to me to use
> search_path for something like that, though.
>
> There's still the problem about the connection pools. pgbouncer could
> consider the binary formats to be an important parameter like the
> database name, where the connection pooler would not mingle connections
> with different settings for binary_formats. That would work, but it
> would be weird because if a new version of a driver adds new binary
> format support, it could cause worse connection pooling performance
> until all the other drivers also support that binary format. I'm not
> sure if that's a major problem or not. Another idea would be for the
> connection pooler to also have a binary_formats config, and it would do
> some checking to make sure all connecting clients understand some
> minimal set of binary formats, so that it could still mingle the
> connections. Either way, I think this is solvable by the connection
> pooler.
>

Well that means that connection poolers have to all be fixed. There are
more than just pgbouncer.
Seems rather harsh that a new feature breaks a connection pooler or makes
the pooler unusable.

Dave