Patch rebased, now ready for review
Dave Cramer On Wed, 4 Mar 2026 at 10:35, Dave Cramer <[email protected]> wrote: > > > 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 >> >
0001-holdable-portals.patch
Description: Binary data
