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>
 <CA+TgmoYr2RsE9OUwo42sxtpHr8gpdTtY6mGrWBbzu2sdFf6s8A@mail.gmail.com>
In-Reply-To: <CA+TgmoYr2RsE9OUwo42sxtpHr8gpdTtY6mGrWBbzu2sdFf6s8A@mail.gmail.com>
From: Dave Cramer <davecramer@gmail.com>
Date: Thu, 15 Jan 2026 14:11:22 -0500
Message-ID: <CADK3HHJ6TqYHgctgOTbuLJNHiKm5i_UE--goMKbcG7+5g2-fpQ@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Robert Haas <robertmhaas@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: multipart/alternative; boundary="000000000000864439064871fe97"
Archived-At: <https://www.postgresql.org/message-id/CADK3HHJ6TqYHgctgOTbuLJNHiKm5i_UE--goMKbcG7%2B5g2-fpQ%40mail.gmail.com>
Precedence: bulk

--000000000000864439064871fe97
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 15 Jan 2026 at 14:00, Robert Haas <robertmhaas@gmail.com> wrote:

> 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 i=
n
> 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

--000000000000864439064871fe97
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><br clear=3D"all"></div><div><div di=
r=3D"ltr" class=3D"gmail_signature">On Thu, 15 Jan 2026 at 14:00, Robert Ha=
as &lt;<a href=3D"mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>&g=
t; wrote:</div></div></div><div class=3D"gmail_quote gmail_quote_container"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jan 15, 2026 at =
5:33=E2=80=AFAM Dave Cramer &lt;<a href=3D"mailto:davecramer@gmail.com" tar=
get=3D"_blank">davecramer@gmail.com</a>&gt; wrote:<br>
&gt; I would argue in the case of &quot;cursor with hold&quot; this should =
have been in the original protocol.<br>
&gt; This is not an added feature this just enables an existing feature in =
the server. This is not unlike widening the cancel key.<br>
&gt; Something like encryption would be a feature that I could see using th=
e extension mechanism<br>
<br>
I agree that encryption is a better fit for the extension mechanism.<br>
But I don&#39;t really agree that this isn&#39;t a new feature. Exposing<br=
>
existing functionality in new ways counts as a new feature in my book.<br>
<br>
&gt;&gt; Having said that, I share Robert&#39;s distaste for &quot;silent&q=
uot; protocol<br>
&gt;&gt; bumps that change the behavior without any negotiation.<br>
&gt;<br>
&gt; My understanding reading his message he was in favour of it<br>
<br>
Well, my feelings are mixed on that point, honestly. If the server<br>
needs to know whether the client supports something, you pretty much<br>
have to have a protocol negotiation of some kind, whether that&#39;s a<br>
version bump or an extension. Otherwise, the server simply has no way<br>
to find out what the client supports. In the opposite direction, it&#39;s<b=
r>
more fuzzy: the client can see the server version number, and so can<br>
draw some conclusions on that basis. We have used this for protocol<br>
changes in the past. However, something like changing the cancel key<br>
or adding cursor with hold affects a lot more clients than adding<br>
CopyBoth that is only triggered by a very specific command in a<br>
special mode. And it&#39;s not that theoretically appealing to conflate<br>
the *protocol* version number with the *server* version number.<br>
Sometimes things that are not theoretically appealing are nonetheless<br>
pragmatically appealing. But it is not really clear to me whether this<br>
is one of those cases, and it sounds like Tom and Jacob think it<br>
isn&#39;t. I could probably be persuaded either way on the best thing to<br=
>
do here in a vacuum, but I&#39;m strongly disinclined to argue against two<=
br>
committers who have a firm position on the topic already.<br>
<br>
I think what I like least about this proposal is the feeling that<br>
we&#39;re about to embark on a long slippery slope of changing the<br>
protocol a little bit in every new PG version. The cancel key thing is<br>
a small change, look here&#39;s another. If we just keep doing that, we&#39=
;ll<br>
end up with either a lot of minor version bumps or a lot of<br>
extensions. I don&#39;t foresee a good outcome either way. This is a<br>
widely used, widely adopted protocol. The idea that we can just start<br>
tweaking it a little bit every year and have nothing bad happened<br>
seems wild, regardless of how we do the tweaking.=C2=A0</blockquote><div><b=
r></div><div>This leaves us with an all or nothing solution, which practica=
lly means we do nothing, since we have to wait until we have a sufficient b=
acklog of=C2=A0</div><div>changes or features to change the protocol. I see=
 that as untenable, unless you are now advocating for using extensions for =
everything ?</div><div><br></div><div>Dave</div></div></div>

--000000000000864439064871fe97--