Re: Proposal to allow setting cursor options on Portals

On Tue, 17 Mar 2026 at 10:41, Dave Cramer <davecramer(at)gmail(dot)com> wrote:

> Patch rebased, now ready for review
>
>
> Dave Cramer
>
>
> On Wed, 4 Mar 2026 at 10:35, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>
>>
>>
>> On Wed, 4 Mar 2026 at 09:26, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>>
>>>
>>>
>>> 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
>>>
>>
>> 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

>