MIME-Version: 1.0
References: 
 <CADK3HHKe1PA1U6aB5-7tWBQ0yZGgNvY7H=ECDD9955Pas_zx_Q@mail.gmail.com>
 <CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
In-Reply-To: 
 <CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
From: Dave Cramer <davecramer@gmail.com>
Date: Mon, 8 Dec 2025 17:07:50 -0500
Message-ID: 
 <CADK3HH+9V58vJzCkgvMwk2fyaCtYwr-Dv5em7rXzgUiVrnpuFA@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Jacob Champion <jacob.champion@enterprisedb.com>
Content-Type: multipart/alternative; boundary="00000000000056c37806457807ee"
Archived-At: 
 <https://www.postgresql.org/message-id/CADK3HH%2B9V58vJzCkgvMwk2fyaCtYwr-Dv5em7rXzgUiVrnpuFA%40mail.gmail.com>
Precedence: bulk

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

On Mon, Dec 8, 2025 at 4:43=E2=80=AFPM Jelte Fennema-Nio <postgres@jeltef.n=
l> wrote:

> On Sun, 7 Dec 2025 at 15:38, Dave Cramer <davecramer@gmail.com> wrote:
> > My main driver here is to allow the creation of Holdable portals at the
> protocol level for drivers.
>
> Overall seems like a sensible feature to want. A somewhat random
> collection of thoughts:
>
> 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.
> 2. I think I like the idea of optional fields that a client can add to
> the existing messages. That way "implementing" the new protocol
> version is a no-op for clients.
> 3. I think we should mark optional fields more clearly in the docs
> somehow. e.g. Make the docs say <term>Optional Int32</term> and
> explain what Optional means in the "Message Data Types" section.
> 4. I think the server should be strict that it only receives this
> optional field for the expected protocol version.
> 5. Do we really need to add the CURSOR_BINARY flag? Seems confusing
> with our other way of indicating binary support, i.e. what does it
> mean to say text as the format code but then specify CURSOR_BINARY.
> 6. What is the benefit of PQsendQueryPreparedWithCursorOptions? I
> understand the use case for PQsendBindWithCursorOptions, but not for
> PQsendQueryPreparedWithCursorOptions.
> 7. The server should check that no unknown flags are passed
> 8. Docs need to be added for the new libpq function(s)
>
> I have one question about your intended usage: I expect you intend to
> make using this opt-in for the users of pgjdbc? (i.e. by using some
> flag/different method to use this HOLD behaviour)


Thx for the comments. Yes JDBC has a holdable resultset as a standard part
of the API

Dave

>
>

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

<div><br></div><div><br></div><div><br><div class=3D"gmail_quote gmail_quot=
e_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Dec 8, 2025 at 4=
:43=E2=80=AFPM 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-width:1px;border-left-style=
:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Sun, 7 Dec 2=
025 at 15:38, Dave Cramer &lt;<a href=3D"mailto:davecramer@gmail.com" targe=
t=3D"_blank">davecramer@gmail.com</a>&gt; wrote:<br>
&gt; My main driver here is to allow the creation of Holdable portals at th=
e protocol level for drivers.<br>
<br>
Overall seems like a sensible feature to want. A somewhat random<br>
collection of thoughts:<br>
<br>
1. We still have fairly limited experience with protocol options, so<br>
afaik not everyone agrees what we should use a version bump for vs a<br>
protocol extension.<br>
2. I think I like the idea of optional fields that a client can add to<br>
the existing messages. That way &quot;implementing&quot; the new protocol<b=
r>
version is a no-op for clients.<br>
3. I think we should mark optional fields more clearly in the docs<br>
somehow. e.g. Make the docs say &lt;term&gt;Optional Int32&lt;/term&gt; and=
<br>
explain what Optional means in the &quot;Message Data Types&quot; section.<=
br>
4. I think the server should be strict that it only receives this<br>
optional field for the expected protocol version.<br>
5. Do we really need to add the CURSOR_BINARY flag? Seems confusing<br>
with our other way of indicating binary support, i.e. what does it<br>
mean to say text as the format code but then specify CURSOR_BINARY.<br>
6. What is the benefit of PQsendQueryPreparedWithCursorOptions? I<br>
understand the use case for PQsendBindWithCursorOptions, but not for<br>
PQsendQueryPreparedWithCursorOptions.<br>
7. The server should check that no unknown flags are passed<br>
8. Docs need to be added for the new libpq function(s)<br>
<br>
I have one question about your intended usage: I expect you intend to<br>
make using this opt-in for the users of pgjdbc? (i.e. by using some<br>
flag/different method to use this HOLD behaviour)</blockquote><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Thx for the comments. Yes JDBC has a holda=
ble resultset as a standard part of the API</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Dave</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;paddin=
g-left:1ex;border-left-color:rgb(204,204,204)" dir=3D"auto"><br>
</blockquote></div></div>

--00000000000056c37806457807ee--