Re: Request for comment on setting binary format output per session
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dave Cramer <davecramer@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-27T01:30:18Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Silence compiler warning introduced in 1edb3b491b
- fba2112b1569 17.0 cited
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