Re: Proposal to allow setting cursor options on Portals

On Thu, 15 Jan 2026 at 16:06, Hannu Krosing <hannuk(at)google(dot)com> 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 <davecramer(at)gmail(dot)com> wrote:
> >
> >
> > On Thu, 15 Jan 2026 at 14:00, Robert Haas <robertmhaas(at)gmail(dot)com> 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