Re: Proposal to allow setting cursor options on Portals
Dave Cramer <davecramer@gmail.com>
From: Dave Cramer <davecramer@gmail.com>
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>
Date: 2026-01-06T12:14:06Z
Lists: pgsql-hackers
On Mon, 15 Dec 2025 at 06:32, Dave Cramer <davecramer@gmail.com> wrote: > > > 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. > Any progress on this ? Dave >
Commits
-
Fix distinctness check for queries with grouping sets
- f00484c170f5 19 (unreleased) cited
-
Provide for forward compatibility with future minor protocol versions.
- ae65f6066dc3 11.0 cited