Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata
От | Jacob Champion |
---|---|
Тема | Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata |
Дата | |
Msg-id | CAOYmi+mSrbN3ML2L7e8+8FO-VYd4Enbyt6NZ_2zrQVHjQTrGxA@mail.gmail.com обсуждение исходный текст |
Ответ на | Proposal: Extending the PostgreSQL Protocol with Command Metadata (Kir Shatrov <sigkirs@gmail.com>) |
Ответы |
Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata
|
Список | pgsql-hackers |
On Sun, Aug 17, 2025 at 5:25 PM Kir Shatrov <sigkirs@gmail.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
В списке pgsql-hackers по дате отправления: