MIME-Version: 1.0
References: <CADK3HHKe1PA1U6aB5-7tWBQ0yZGgNvY7H=ECDD9955Pas_zx_Q@mail.gmail.com>
 <CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
 <CAOYmi+nVQRpSs3vd_v9L8ytO9wnL2ndnzGwU31aDGorVFxrAYA@mail.gmail.com>
 <CAGECzQSZ43JMjA8QEJoF9DCdTO0GQeR2qyhouQciSG2ik40Yhg@mail.gmail.com>
 <CAOYmi+m20jS8zZ2qFpSnvhaqGDX+vtgCsqcu9VhokyLqF8kFag@mail.gmail.com>
 <CADK3HH+DPY_x_H=e0c_AVWoUP9E+YXdyJDVvmzYEYxZXT87Agw@mail.gmail.com>
 <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com>
 <CADK3HHKDrnRAoAcUv1ucLB0o_ZUcJRwm+jonNPNUHoDtcA9Crw@mail.gmail.com>
 <CAGECzQQriv-h_h8Ygxh_RfnLt2G4P9nWrpgMi9YL2bmcOLbUEA@mail.gmail.com>
 <CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@mail.gmail.com>
 <CADK3HH+o9dTYsXpCk7-Z0JW-QB2TV7=e97O8B-XDOGQb14AfSQ@mail.gmail.com>
 <CAOYmi+kkTbuwGa9X=XomNivAw9P4hN3M1U7QXiP7Jw+nrQXtNQ@mail.gmail.com>
 <CAGECzQSfCPXdOpUKfdkPA9iZhGyRjZAad-CXbhApZ2CnjgG2kw@mail.gmail.com>
 <CAOYmi+=qE1khrtTD7oQVPJQTHoXffQQ0DPHOx870r7801zhw9g@mail.gmail.com>
 <2155281.1767900170@sss.pgh.pa.us> <CADK3HH+6MTrMBsW+iDJ0VGzu7HQKJLLQbjnbdps3kK8Ug5prUg@mail.gmail.com>
 <CA+TgmoavFJW984Y8cUv-U9K+JqxYgqEj-i1A1dORwvyki5642A@mail.gmail.com>
 <CAGECzQSHKR2LtBSnDT_bjdpE1=cVzZLRcb2k5d_K=BMvJCFihg@mail.gmail.com>
 <431484.1768433414@sss.pgh.pa.us> <CADK3HH+TnNaW-b+d8xkUDcFZ-4oWhh5q3hCzbyuR9ShwMasHrA@mail.gmail.com>
In-Reply-To: <CADK3HH+TnNaW-b+d8xkUDcFZ-4oWhh5q3hCzbyuR9ShwMasHrA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 15 Jan 2026 14:00:00 -0500
Message-ID: <CA+TgmoYr2RsE9OUwo42sxtpHr8gpdTtY6mGrWBbzu2sdFf6s8A@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Dave Cramer <davecramer@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jelte Fennema-Nio <postgres@jeltef.nl>, 
	Jacob Champion <jacob.champion@enterprisedb.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoYr2RsE9OUwo42sxtpHr8gpdTtY6mGrWBbzu2sdFf6s8A%40mail.gmail.com>
Precedence: bulk

On Thu, Jan 15, 2026 at 5:33=E2=80=AFAM 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 e=
xtension 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.

> As for proxies or "middleboxes" I will concede that not advertising that =
we are going to change that message is a non-starter

Yeah.

--=20
Robert Haas
EDB: http://www.enterprisedb.com