Re: Proposal to allow setting cursor options on Portals

On Thu, 8 Jan 2026 at 14:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

For the particular case of adding the ability to create holdable cursors at
the protocol level which is what my patch is concerned with I don't think
it's even necessary to bump the protocol or create a protocol extension.
The change in the message is backward compatible and clients only need to
know that after version 18 they can use the message to create a holdable
cursor. I would argue that this patch is just rectifying an oversight in
the original protocol.

Dave