On Wed, 4 Mar 2026 at 09:26, Dave Cramer <[email protected]> wrote:
> > > On Thu, 15 Jan 2026 at 16:06, Hannu Krosing <[email protected]> wrote: > >> 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 >> > > I have modified the patch to use protocol options instead of protocol > version > resending with a different patch name as I think the commitfest app won't pick it up with the same name > > See new version attached >
0002-wip-holdable-portals.patch
Description: Binary data
