Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Date
Msg-id CAGECzQRWw4PibMvr7YpyidvxPpHw3uTXKi7O1CXfc0ps0q2xuw@mail.gmail.com
Whole thread Raw
In response to Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 23 May 2024 at 20:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
> > Would it be good to expand on that idea of criticality? IIRC one of
> > Jelte's complaints earlier was that middleware has to know all the
> > extension types anyway, to be able to figure out whether it has to do
> > something about them or not. HTTP has the concept of hop-by-hop vs
> > end-to-end headers for related reasons.
>
> Yeah, perhaps.  We'd need to figure out just which classes we need
> to divide protocol parameters into, and then think about a way for
> code to understand which class a parameter falls into even when
> it doesn't specifically know that parameter.

I think this class is so rare, that it's not worth complicating the
discussion on new protocol features even more. AFAICT there is only
one proposed protocol change that does not need any pooler support
(apart from syncing the feature value when re-assigning the
connectin): Automatic binary encoding for a list of types

All others need some support from poolers, at the very least they need
new message types to not error out. But in many cases more complex
stuff is needed.



pgsql-hackers by date:

Previous
From: walther@technowledgy.de
Date:
Subject: Re: Schema variables - new implementation for Postgres 15
Next
From: "Long Song"
Date:
Subject: [PATCH]A minor improvement to the error-report in SimpleLruWriteAll()