Re: Proposal to allow setting cursor options on Portals

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