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

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

In response to

Responses

Browse pgsql-hackers by date

  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:.//...)