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>
In-Reply-To: 
 <CAGECzQQriv-h_h8Ygxh_RfnLt2G4P9nWrpgMi9YL2bmcOLbUEA@mail.gmail.com>
From: Dave Cramer <davecramer@gmail.com>
Date: Mon, 15 Dec 2025 06:32:18 -0500
Message-ID: 
 <CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@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="000000000000b3e56c0645fbf7f7"
Archived-At: 
 <https://www.postgresql.org/message-id/CADK3HHL_cUzm-R%2B0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9%3DtbeA%40mail.gmail.com>
Precedence: bulk

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

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

> On Sun, 14 Dec 2025 at 14:49, Dave Cramer <davecramer@gmail.com> wrote:
> > 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.
>
> I agree drivers would like binary results back, but it's unclear to me
> how CURSOR_OPT_BINARY is different from setting the result column
> format codes to an array of a single 1? That should also change all
> columns to be binary right?
>

Fair point.

>
> > 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.
>
> I get what you mean, but I feel like we should at least be concerned
> with popular ecosystem tools like, pgbouncer and pgpool. But then it
> quickly becomes an exercise in where we draw the line, what about
> postgres forks like Yugabyte? Or things very similar like cockroachdb.
> Both of those are distributed, and probably don't use our LSNs. So as
> a concrete example, if we add LSNs to the protocol, it would be nice
> to work with their version too if it's not too much effort. e.g. by
> specifing a length for the commit id in the protocol instead of
> forcing it at the protocol level to always be a 64bit integer.
>

It would make sense to be forward looking here in the event that Postgres
ever has wider LSN's agreed.

Dave

--000000000000b3e56c0645fbf7f7
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 09:04, 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 14:49, Dave Cramer &lt;=
<a href=3D"mailto:davecramer@gmail.com" target=3D"_blank">davecramer@gmail.=
com</a>&gt; wrote:<br>
&gt; Here I was thinking that binary was the one that did make sense. The p=
gjdbc driver would like the results back in binary, I believe others would =
as well.<br>
<br>
I agree drivers would like binary results back, but it&#39;s unclear to me<=
br>
how CURSOR_OPT_BINARY is different from setting the result column<br>
format codes to an array of a single 1? That should also change all<br>
columns to be binary right?<br></blockquote><div><br></div><div>Fair point.=
=C2=A0</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>
&gt; Fair, but from my POV, we are only concerned with Postgres. I would sa=
y it&#39;s up to the other implementations to deal with incompatibilities.<=
br>
<br>
I get what you mean, but I feel like we should at least be concerned<br>
with popular ecosystem tools like, pgbouncer and pgpool. But then it<br>
quickly becomes an exercise in where we draw the line, what about<br>
postgres forks like Yugabyte? Or things very similar like cockroachdb.<br>
Both of those are distributed, and probably don&#39;t use our LSNs. So as<b=
r>
a concrete example, if we add LSNs to the protocol, it would be nice<br>
to work with their version too if it&#39;s not too much effort. e.g. by<br>
specifing a length for the commit id in the protocol instead of<br>
forcing it at the protocol level to always be a 64bit integer.<br></blockqu=
ote><div><br></div><div>It would make sense to be forward looking here in t=
he event that Postgres ever has wider LSN&#39;s=C2=A0agreed.</div><div><br>=
</div><div>Dave=C2=A0</div></div></div>

--000000000000b3e56c0645fbf7f7--