Re: Proposal to allow setting cursor options on Portals
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>,
Jacob Champion <jacob.champion@enterprisedb.com>,
Dave Cramer <davecramer@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2026-01-08T19:22:50Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > That sounds like the right approach to me. Note that I have also > previously expressed my disagreement with the idea of bumping the > protocol version regularly. I'm not entirely comfortable with the idea > of using protocol extensions for everything, because I really imagined > that they would be used for larger features that made a cluster of > related changes rather than solitary changes, and that there wouldn't > be many of them. I kind of doubt that there will ever be many of them, but if we start to feel like there's a lot, we could invent abbreviations: single feature names that clients can ask for that are defined to represent a particular set of older features. But I'd argue that those sets should be groups of related functions, not "whatever random stuff exists as of Postgres 27". I think it'll be highly useful for clients to declare which features they want, rather than leave people wondering exactly which features this client intends to support. regards, tom lane
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