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
-
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