Re: Proposal to allow setting cursor options on Portals - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal to allow setting cursor options on Portals
Date
Msg-id 2155281.1767900170@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal to allow setting cursor options on Portals  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Proposal to allow setting cursor options on Portals
List 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



pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: pg_plan_advice
Next
From: Robert Haas
Date:
Subject: Re: pg_plan_advice