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>
In-Reply-To: 
 <CAOYmi+nVQRpSs3vd_v9L8ytO9wnL2ndnzGwU31aDGorVFxrAYA@mail.gmail.com>
From: Dave Cramer <davecramer@gmail.com>
Date: Sun, 14 Dec 2025 07:15:22 -0500
Message-ID: 
 <CADK3HHJVX_H+8ge+vMzU35CzbUSCw08FJ_1G39m2-SLwM3V6pQ@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: multipart/alternative; boundary="000000000000ced4010645e8739e"
Archived-At: 
 <https://www.postgresql.org/message-id/CADK3HHJVX_H%2B8ge%2BvMzU35CzbUSCw08FJ_1G39m2-SLwM3V6pQ%40mail.gmail.com>
Precedence: bulk

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

On Wed, 10 Dec 2025 at 12:41, Jacob Champion <
jacob.champion@enterprisedb.com> wrote:

> On Mon, Dec 8, 2025 at 1:43=E2=80=AFPM Jelte Fennema-Nio <postgres@jeltef=
.nl>
> wrote:
> > 1. We still have fairly limited experience with protocol options, so
> > afaik not everyone agrees what we should use a version bump for vs a
> > protocol extension.
>
> I think it'd be helpful for proposals to describe why a minor version
> bump was chosen over a protocol extension parameter (or vice versa),
> so that we can begin to develop some consensus.
>

 The reasons I chose a protocol bump include:
1/ I actually think this was an oversight from the original spec. I am not
adding any new features to the server, only implementing existing options
on a portal/cursor that should have been in the original protocol
2/ I'm hoping and expect that there will be other additions to the protocol
for 3.3 such as returning the LSN after commit, binary return values per
session

>
> To me, the conversation on the wire for this feature seems perfect for
> an extension parameter: "Hello server, do you support this optional
> thing in this one message type? If not, let me know." Especially since
> the optional thing is itself an extensible bitmap! With the
> minor-version strategy, if we added new bits in 3.6, clients who just
> wanted those new bits would then have to implement support for every
> feature in versions 3.4, 3.5, and 3.6 just to improve that one use
> case, and that incentive mismatch leads to more ossification IMO.
>
> =3D Soapbox Follows =3D
>
> I've talked about it face-to-face with people, but to go on the public
> record: I don't think this is a wise use of a minor version upgrade
> strategy. I prefer protocol architectures that introduce separate
> extensions first, then periodically bundle the critical and
> highly-used extensions into a new minor version once they're sure that
> _everyone_ should support those things.
>
> I know that 3.2 didn't do that. My view of 3.2 is that it was a big
> compromise to get some things unstuck, so overall I'm glad we have it
> -- but now that we have it, I'd rather that 3.next be more
> intentional. Plus I think it's unwise to introduce a 3.3 before we're
> confident that 3.2 can be widely deployed, and I'm trying to put
> effort into the latter for 19, so that I'm not just sitting here
> gatekeeping.
>
> pgjdbc already supports 3.2. Unfortunately we have no idea how many peopl=
e
actually use it.


> IETF has a bunch of related case studies [1,2,3] that might be useful
> reading, even if we decide that their experience differs heavily from
> ours.
>

I read the articles which sadly gloss over protocol negotiation issues.

Dave

>
>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div></div><div class=3D"gmail_=
quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, =
10 Dec 2025 at 12:41, Jacob Champion &lt;<a href=3D"mailto:jacob.champion@e=
nterprisedb.com">jacob.champion@enterprisedb.com</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Dec 8, 2025 at 1:43=
=E2=80=AFPM Jelte Fennema-Nio &lt;<a href=3D"mailto:postgres@jeltef.nl" tar=
get=3D"_blank">postgres@jeltef.nl</a>&gt; wrote:<br>
&gt; 1. We still have fairly limited experience with protocol options, so<b=
r>
&gt; afaik not everyone agrees what we should use a version bump for vs a<b=
r>
&gt; protocol extension.<br>
<br>
I think it&#39;d be helpful for proposals to describe why a minor version<b=
r>
bump was chosen over a protocol extension parameter (or vice versa),<br>
so that we can begin to develop some consensus.<br></blockquote><div><br></=
div><div>=C2=A0The reasons I chose a protocol bump include:</div><div>1/ I =
actually think this was an oversight from the original spec. I am not addin=
g any new features to the server, only implementing existing options on a p=
ortal/cursor that should have been in the original protocol</div><div>2/ I&=
#39;m hoping and expect that there will be other additions to the protocol =
for 3.3 such as returning the LSN after commit, binary return values per se=
ssion</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
To me, the conversation on the wire for this feature seems perfect for<br>
an extension parameter: &quot;Hello server, do you support this optional<br=
>
thing in this one message type? If not, let me know.&quot; Especially since=
<br>
the optional thing is itself an extensible bitmap! With the<br>
minor-version strategy, if we added new bits in 3.6, clients who just<br>
wanted those new bits would then have to implement support for every<br>
feature in versions 3.4, 3.5, and 3.6 just to improve that one use<br>
case, and that incentive mismatch leads to more ossification IMO.<br>
<br>
=3D Soapbox Follows =3D<br>
<br>
I&#39;ve talked about it face-to-face with people, but to go on the public<=
br>
record: I don&#39;t think this is a wise use of a minor version upgrade<br>
strategy. I prefer protocol architectures that introduce separate<br>
extensions first, then periodically bundle the critical and<br>
highly-used extensions into a new minor version once they&#39;re sure that<=
br>
_everyone_ should support those things.<br>
<br>
I know that 3.2 didn&#39;t do that. My view of 3.2 is that it was a big<br>
compromise to get some things unstuck, so overall I&#39;m glad we have it<b=
r>
-- but now that we have it, I&#39;d rather that 3.next be more<br>
intentional. Plus I think it&#39;s unwise to introduce a 3.3 before we&#39;=
re<br>
confident that 3.2 can be widely deployed, and I&#39;m trying to put<br>
effort into the latter for 19, so that I&#39;m not just sitting here<br>
gatekeeping.<br>
<br></blockquote><div>pgjdbc already supports 3.2. Unfortunately we have no=
 idea how many people actually use it.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">
IETF has a bunch of related case studies [1,2,3] that might be useful<br>
reading, even if we decide that their experience differs heavily from<br>
ours.<br></blockquote><div><br></div><div>I read the articles which sadly g=
loss over protocol negotiation issues.</div><div><br></div><div>Dave=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><br>
</blockquote></div></div>

--000000000000ced4010645e8739e--