First, let me say that I very much support getting this into the wire protocol.
As for ways to extend the protocol, I have been myself working on another patch + extension where one can return extra info in ReadyForQuery message The first things to add are * CommitLSN so we can make use of ability to WAIT FOR LSN on replica and two connection-pooling helpers * a flag telling that there are HOLD CURSORS * a flag telling that there are temp tables This extra feedback is enabled by setting a flag, so no flag -- nothing to confuse the client. The extras themselves are uniform (length, tag, data) so client can ignore any tag they do not recognize. On Thu, Jan 15, 2026 at 8:11 PM Dave Cramer <[email protected]> wrote: > > > On Thu, 15 Jan 2026 at 14:00, Robert Haas <[email protected]> wrote: >> ... >> I think what I like least about this proposal is the feeling that >> we're about to embark on a long slippery slope of changing the >> protocol a little bit in every new PG version. The cancel key thing is >> a small change, look here's another. If we just keep doing that, we'll >> end up with either a lot of minor version bumps or a lot of >> extensions. I don't foresee a good outcome either way. This is a >> widely used, widely adopted protocol. The idea that we can just start >> tweaking it a little bit every year and have nothing bad happened >> seems wild, regardless of how we do the tweaking. I think "tweaking ait little bit" and only whhere needed is exactly the right approach, if it can be cleanly isolated. My approach to protocol extension modulation *is* the ability to enable different parts of the protocol individually. For example the protocol extension to allow cursor/portal flags could be implemented this way Client has to set a flag to PROTOCOL_PORTAL_OPTIONS=true to tell the server that new protocol messages are coming - If flag setting fails, client will not send the new protocol messages - If flag setting succeeds, then it is ok to send the new messages corresponding to the flag. This way the extra packets are disconnected from protocol version and can be enabled/disabled individually and per connection And it also lets one cleanly backport the change as needed without affecting anything else. > This leaves us with an all or nothing solution, which practically means we do > nothing, since we have to wait until we have a sufficient backlog of > changes or features to change the protocol. I see that as untenable, unless > you are now advocating for using extensions for everything ? > > Dave
