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>
In-Reply-To: 
 <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com>
From: Dave Cramer <davecramer@gmail.com>
Date: Sun, 14 Dec 2025 08:48:57 -0500
Message-ID: 
 <CADK3HHKDrnRAoAcUv1ucLB0o_ZUcJRwm+jonNPNUHoDtcA9Crw@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: multipart/alternative; boundary="000000000000756cf60645e9c21f"
Archived-At: 
 <https://www.postgresql.org/message-id/CADK3HHKDrnRAoAcUv1ucLB0o_ZUcJRwm%2BjonNPNUHoDtcA9Crw%40mail.gmail.com>
Precedence: bulk

--000000000000756cf60645e9c21f
Content-Type: text/plain; charset="UTF-8"

On Sun, 14 Dec 2025 at 08:42, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:

> On Sun, 14 Dec 2025 at 13:31, Dave Cramer <davecramer@gmail.com> wrote:
> >> Exactly. Don't you want to make sure that clients in the ecosystem are
> >> able to use this _before_ we rev the version again, and again? We
> >> don't ever get these numbers back.
> >
> > Well there are 97 of them. 1 per year is a long time.
>
> I don't think Jacob was concerned about the actual numbers running
> out, but in case he was: it's actually 9997 versions that we still
> have (9996 after we'd commit the grease proposal[1]).
>
> [1]: https://commitfest.postgresql.org/patch/6157/
>
> > FWIW, HOLDABLE cursors are not the only option this enables. It enables
> all of the other cursor options.
>
> As mentioned upthread, I'm not sure BINARY makes sense. For any other
> options, the protocol docs should specify which ones are allowed and
> what their bits are. Looking at the DECLARE docs[2].
>

Here I was thinking that binary was the one that did make sense. The pgjdbc
driver would like the results back in binary, I believe others would as
well.


> 1. I think supporting ASENSITVE/INSENSITIVE/SENSITIVE bits is
> unnecessary, since postgres cursors are always INSENSITIVE.
> 2. For SCROLL vs NO SCROLL, it would be nice if we could get rid of
> the intermediate mode where if neither SCROLL or NO SCROLL is
> specified, it's still SCROLL sometimes. I'm not sure backwards
> compatibility would allow that, i.e. can you currently sometimes do a
> BACKWARD scan on a portal created with Bind. I guess we could make it
> so that if you specify the portal flags, then you have to be explicit
> abuot specifying SCROLL or NO SCROLL
> 3. All the flags with no SQL variant probably shouldn't be
> configurable through the protocol too (e.g. CURSOR_OPT_FAST_PLAN)
>
> [2]: https://www.postgresql.org/docs/18/sql-declare.html
>
> > Are we concerned with servers that are not compatible with Postgres ?
>
> I think there's enough re-implementations of the postgres protocol by
> other databases that it would be a shame if we didn't even try to
> consider them, but I wouldn't consider it critical to get it right.
> Since they can always throw application errors for features they don't
> support, just like they do now for SQL that they don't support. They
> can always contribute changes to clients to make using unsupported
> features opt-in in the rare case where they are not.
>

Fair, but from my POV, we are only concerned with Postgres. I would say
it's up to the other implementations to deal with incompatibilities.

Dave

--000000000000756cf60645e9c21f
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 S=
un, 14 Dec 2025 at 08:42, Jelte Fennema-Nio &lt;<a href=3D"mailto:postgres@=
jeltef.nl">postgres@jeltef.nl</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Sun, 14 Dec 2025 at 13:31, Dave Cramer &lt;=
<a href=3D"mailto:davecramer@gmail.com" target=3D"_blank">davecramer@gmail.=
com</a>&gt; wrote:<br>
&gt;&gt; Exactly. Don&#39;t you want to make sure that clients in the ecosy=
stem are<br>
&gt;&gt; able to use this _before_ we rev the version again, and again? We<=
br>
&gt;&gt; don&#39;t ever get these numbers back.<br>
&gt;<br>
&gt; Well there are 97 of them. 1 per year is a long time.<br>
<br>
I don&#39;t think Jacob was concerned about the actual numbers running<br>
out, but in case he was: it&#39;s actually 9997 versions that we still<br>
have (9996 after we&#39;d commit the grease proposal[1]).<br>
<br>
[1]: <a href=3D"https://commitfest.postgresql.org/patch/6157/" rel=3D"noref=
errer" target=3D"_blank">https://commitfest.postgresql.org/patch/6157/</a><=
br>
<br>
&gt; FWIW, HOLDABLE cursors are not the only option this enables. It enable=
s all of the other cursor options.<br>
<br>
As mentioned upthread, I&#39;m not sure BINARY makes sense. For any other<b=
r>
options, the protocol docs should specify which ones are allowed and<br>
what their bits are. Looking at the DECLARE docs[2].<br></blockquote><div><=
br></div><div>Here I was thinking that binary was the one that did make sen=
se. The pgjdbc driver would like the results back in binary, I believe othe=
rs would as well.</div><div><br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
1. I think supporting ASENSITVE/INSENSITIVE/SENSITIVE bits is<br>
unnecessary, since postgres cursors are always INSENSITIVE.<br>
2. For SCROLL vs NO SCROLL, it would be nice if we could get rid of<br>
the intermediate mode where if neither SCROLL or NO SCROLL is<br>
specified, it&#39;s still SCROLL sometimes. I&#39;m not sure backwards<br>
compatibility would allow that, i.e. can you currently sometimes do a<br>
BACKWARD scan on a portal created with Bind. I guess we could make it<br>
so that if you specify the portal flags, then you have to be explicit<br>
abuot specifying SCROLL or NO SCROLL<br>
3. All the flags with no SQL variant probably shouldn&#39;t be<br>
configurable through the protocol too (e.g. CURSOR_OPT_FAST_PLAN)<br>
<br>
[2]: <a href=3D"https://www.postgresql.org/docs/18/sql-declare.html" rel=3D=
"noreferrer" target=3D"_blank">https://www.postgresql.org/docs/18/sql-decla=
re.html</a><br>
<br>
&gt; Are we concerned with servers that are not compatible with Postgres ?<=
br>
<br>
I think there&#39;s enough re-implementations of the postgres protocol by<b=
r>
other databases that it would be a shame if we didn&#39;t even try to<br>
consider them, but I wouldn&#39;t consider it critical to get it right.<br>
Since they can always throw application errors for features they don&#39;t<=
br>
support, just like they do now for SQL that they don&#39;t support. They<br=
>
can always contribute changes to clients to make using unsupported<br>
features opt-in in the rare case where they are not.<br></blockquote><div><=
br></div><div>Fair, but from my POV, we are only concerned with Postgres. I=
 would say it&#39;s up to the other implementations to deal with incompatib=
ilities.</div><div><br></div><div>Dave=C2=A0</div></div></div>

--000000000000756cf60645e9c21f--