Re: Request for comment on setting binary format output per session - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Request for comment on setting binary format output per session
Date
Msg-id CADK3HHKM3ANkQGwV_On-ovQHL--yLKd7KzBZXEwQ6FzmxNXafw@mail.gmail.com
Whole thread Raw
In response to Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Request for comment on setting binary format output per session  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers

Dave Cramer


On Sat, 25 Mar 2023 at 19:06, Jeff Davis <pgsql@j-davis.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

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Request for comment on setting binary format output per session
Next
From: Justin Pryzby
Date:
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL