Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata

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

In response to

Responses

Browse pgsql-hackers by date

  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