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>
 <CA+TgmoZyh3gGazhu3kvz4LNSyh6ifUx-sSCyiAoJ+3EnyBSVZg@mail.gmail.com> <2155281.1767900170@sss.pgh.pa.us>
In-Reply-To: <2155281.1767900170@sss.pgh.pa.us>
From: Dave Cramer <davecramer@gmail.com>
Date: Fri, 9 Jan 2026 13:20:34 -0500
Message-ID: <CADK3HH+6MTrMBsW+iDJ0VGzu7HQKJLLQbjnbdps3kK8Ug5prUg@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, 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="000000000000c6deda0647f89543"
Archived-At: <https://www.postgresql.org/message-id/CADK3HH%2B6MTrMBsW%2BiDJ0VGzu7HQKJLLQbjnbdps3kK8Ug5prUg%40mail.gmail.com>
Precedence: bulk

--000000000000c6deda0647f89543
Content-Type: text/plain; charset="UTF-8"

On Thu, 8 Jan 2026 at 14:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
> > That sounds like the right approach to me. Note that I have also
> > previously expressed my disagreement with the idea of bumping the
> > protocol version regularly. I'm not entirely comfortable with the idea
> > of using protocol extensions for everything, because I really imagined
> > that they would be used for larger features that made a cluster of
> > related changes rather than solitary changes, and that there wouldn't
> > be many of them.
>
> I kind of doubt that there will ever be many of them, but if we start
> to feel like there's a lot, we could invent abbreviations: single
> feature names that clients can ask for that are defined to represent
> a particular set of older features.  But I'd argue that those sets
> should be groups of related functions, not "whatever random stuff
> exists as of Postgres 27".  I think it'll be highly useful for clients
> to declare which features they want, rather than leave people
> wondering exactly which features this client intends to support.
>
>                         regards, tom lane
>


For the particular case of adding the ability to create holdable cursors at
the protocol level which is what my patch is concerned with I don't think
it's even necessary to bump the protocol or create a protocol extension.
The change in the message is backward compatible and clients only need to
know that after version 18 they can use the message to create a holdable
cursor. I would argue that this patch is just rectifying an oversight in
the original protocol.

Dave

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div></div><br><div class=3D"gm=
ail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, 8 Jan 2026 at 14:22, Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us">=
tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Robert Haas &lt;<a href=3D"mailto:robertmhaas@gmail.com" t=
arget=3D"_blank">robertmhaas@gmail.com</a>&gt; writes:<br>
&gt; That sounds like the right approach to me. Note that I have also<br>
&gt; previously expressed my disagreement with the idea of bumping the<br>
&gt; protocol version regularly. I&#39;m not entirely comfortable with the =
idea<br>
&gt; of using protocol extensions for everything, because I really imagined=
<br>
&gt; that they would be used for larger features that made a cluster of<br>
&gt; related changes rather than solitary changes, and that there wouldn=
9;t<br>
&gt; be many of them.<br>
<br>
I kind of doubt that there will ever be many of them, but if we start<br>
to feel like there&#39;s a lot, we could invent abbreviations: single<br>
feature names that clients can ask for that are defined to represent<br>
a particular set of older features.=C2=A0 But I&#39;d argue that those sets=
<br>
should be groups of related functions, not &quot;whatever random stuff<br>
exists as of Postgres 27&quot;.=C2=A0 I think it&#39;ll be highly useful fo=
r clients<br>
to declare which features they want, rather than leave people<br>
wondering exactly which features this client intends to support.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br></blockquote><div><br></div><div><br></div>=
<div>For the particular case of adding the ability to create holdable curso=
rs at the protocol level which is what my patch is concerned with I don&#39=
;t think it&#39;s even necessary to bump the protocol or create a protocol =
extension.</div><div>The change in the message is backward compatible and c=
lients only need to know that after version 18 they can use the message to =
create a holdable cursor. I would argue that this patch is just rectifying =
an oversight in the original protocol.</div><div><br></div><div>Dave</div><=
/div></div>

--000000000000c6deda0647f89543--