From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dave Cramer <davecramer(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Request for comment on setting binary format output per session |
Date: | 2023-03-27 01:30:18 |
Message-ID: | 3062359.1679880618@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dave Cramer <davecramer(at)gmail(dot)com> writes:
> On Sun, 26 Mar 2023 at 18:12, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2023-03-27 01:32:27 | Re: logical decoding and replication of sequences, take 2 |
Previous Message | Justin Pryzby | 2023-03-27 01:22:00 | Re: Documentation Not Compiling (http://docbook... not https:.//...) |