Re: Proposal to allow setting cursor options on Portals - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: Proposal to allow setting cursor options on Portals
Date
Msg-id CADK3HHJ6TqYHgctgOTbuLJNHiKm5i_UE--goMKbcG7+5g2-fpQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to allow setting cursor options on Portals  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Proposal to allow setting cursor options on Portals
List pgsql-hackers

On Thu, 15 Jan 2026 at 14:00, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jan 15, 2026 at 5:33 AM Dave Cramer <davecramer@gmail.com> wrote:
> I would argue in the case of "cursor with hold" this should have been in the original protocol.
> This is not an added feature this just enables an existing feature in the server. This is not unlike widening the cancel key.
> Something like encryption would be a feature that I could see using the extension mechanism

I agree that encryption is a better fit for the extension mechanism.
But I don't really agree that this isn't a new feature. Exposing
existing functionality in new ways counts as a new feature in my book.

>> Having said that, I share Robert's distaste for "silent" protocol
>> bumps that change the behavior without any negotiation.
>
> My understanding reading his message he was in favour of it

Well, my feelings are mixed on that point, honestly. If the server
needs to know whether the client supports something, you pretty much
have to have a protocol negotiation of some kind, whether that's a
version bump or an extension. Otherwise, the server simply has no way
to find out what the client supports. In the opposite direction, it's
more fuzzy: the client can see the server version number, and so can
draw some conclusions on that basis. We have used this for protocol
changes in the past. However, something like changing the cancel key
or adding cursor with hold affects a lot more clients than adding
CopyBoth that is only triggered by a very specific command in a
special mode. And it's not that theoretically appealing to conflate
the *protocol* version number with the *server* version number.
Sometimes things that are not theoretically appealing are nonetheless
pragmatically appealing. But it is not really clear to me whether this
is one of those cases, and it sounds like Tom and Jacob think it
isn't. I could probably be persuaded either way on the best thing to
do here in a vacuum, but I'm strongly disinclined to argue against two
committers who have a firm position on the topic already.

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. 

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

pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Can we change pg_rewind used without wal_log_hints and data_checksums
Next
From: Heikki Linnakangas
Date:
Subject: Re: Fix possible 'unexpected data beyond EOF' on replica restart