Re: Proposal to allow setting cursor options on Portals

Jelte Fennema-Nio <postgres@jeltef.nl>

From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Dave Cramer <davecramer@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2026-01-07T14:48:10Z
Lists: pgsql-hackers
On Tue, 6 Jan 2026 at 17:17, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Well, I'd hoped that you and Jelte would maybe hash out your
> differences in opinion a bit before I jumped back in. You think
> extensions are orthogonal -- seemingly negating the primary advantage
> cited for regular minor bumps? -- but Jelte is optimizing for
> interrelated features.

I had a quick discord chat with Dave. And we don't disagree much with
each other: We both would like to use a version bump for these kinds
of very simple to implement features.

For an important part because we hope to do multiple of such small
changes in a single PG release, so the protocol can actually move
forward at a decent speed. Having a single version is only 1 option,
while having N protocol extensions a year gives at least N different
configurations (if they're all orthogonal, and at worst N*N).

In your first email you (Jacob) wrote this:
> 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.

Dave and I both agree that if we create a protocol extension for every
tiny feature and then in 3 years include some of them in a protocol
bump, that's just a lot more complexity that every client author will
have to deal with in the long run.



Commits

  1. Fix distinctness check for queries with grouping sets

  2. Provide for forward compatibility with future minor protocol versions.