From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Kir Shatrov <sigkirs(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata |
Date: | 2025-08-18 16:05:16 |
Message-ID: | CAOYmi+mSrbN3ML2L7e8+8FO-VYd4Enbyt6NZ_2zrQVHjQTrGxA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Aug 17, 2025 at 5:25 PM Kir Shatrov <sigkirs(at)gmail(dot)com> wrote:
> Is there interest in this type of protocol extension?
There have been previous requests for baking custom trace IDs and WAL
information into the protocol; the wiki is down right now but I recall
some discussion at maybe the 2024 unconference?
> What concerns do you have about protocol extensions in general?
> Would you prefer a different approach (e.g., separate protocol messages vs. extending existing ones)?
FYI, the community is in the process of breaking up logjams in the
protocol definition. There is some not-insignificant disagreement on
how protocol extensions should be built and maintained, but there is
also recent progress on that front, so I just want to prep you for
that. :D
I haven't looked into the proposal in great detail, but one thing that
caught my eye was (what I consider to be) a layering violation, where
the client advertises its interest in metadata at the protocol level
and then specifies the messages at the SQL level. I know the SQL
function you provided is for illustration and test purposes, but it
still highlights the question of "how do we decide what's interesting
(and to whom)?"
I'd imagine that question will be a little bit difficult for
intermediaries such as pgbouncer to navigate, especially if the client
and proxy have different-but-overlapping interests. (In fact I wonder
if this is going to once again poke at the lack of end-to-end vs
hop-by-hop protocol extensions.) Unless the plan is to push everything
that could possibly be interesting into every response?
Thanks!
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2025-08-18 16:13:44 | Re: When deleting the plpgsql function, release the CachedPlan of the function |
Previous Message | Daniel Verite | 2025-08-18 15:56:01 | Re: fixing tsearch locale support |