On Tue, 17 Mar 2026 at 10:41, Dave Cramer <[email protected]> wrote:
> 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 >> > Apparently that patch does not apply. Checked this one against master Dave >
0002-holdable-portals.patch
Description: Binary data
