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 See new version attached
0001-wip-holdable-portals.patch
Description: Binary data
