| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Dave Cramer <davecramer(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Proposal to allow setting cursor options on Portals |
| Date: | 2026-01-08 19:22:50 |
| Message-ID: | 2155281.1767900170@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-01-08 19:23:48 | Re: pg_plan_advice |
| Previous Message | Lukas Fittl | 2026-01-08 19:13:43 | Re: pg_plan_advice |