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

From Tom Lane
Subject Re: Request for comment on setting binary format output per session
Date
Msg-id 3062359.1679880618@sss.pgh.pa.us
Whole thread Raw
In response to Re: Request for comment on setting binary format output per session  (Dave Cramer <davecramer@gmail.com>)
Responses Re: Request for comment on setting binary format output per session  (Dave Cramer <davecramer@gmail.com>)
List pgsql-hackers
Dave Cramer <davecramer@gmail.com> writes:
> On Sun, 26 Mar 2023 at 18:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I would not expect DISCARD ALL to reset a session-level property.

> Well if we can't reset it with DISCARD ALL how would that work with
> pgbouncer, or any pool for that matter since it doesn't know which client
> asked for which (if any) OID's to be binary.

Well, it'd need to know that, just like it already needs to know
which clients asked for which database or which login role.
Having DISCARD ALL reset those session properties is obviously silly.

The way I'm imagining this working is that it fits into the framework
for protocol options (cf commits ae65f6066 and bbf9c282c), whereby
the client and server negotiate whether they can handle this feature.
A non-updated pooler would act like a server that doesn't know the
feature, and the client would have to fall back to not using it,
just as it would with an older server.

I doubt that this would crimp a pooler's freedom of action very much.
In any given environment there will probably be only a few values of
the set-of-okay-types in use.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Documentation Not Compiling (http://docbook... not https:.//...)
Next
From: Masahiko Sawada
Date:
Subject: Re: logical decoding and replication of sequences, take 2