Re: Proposal to allow setting cursor options on Portals

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Proposal to allow setting cursor options on Portals
Дата
Msg-id CADK3HH+6MTrMBsW+iDJ0VGzu7HQKJLLQbjnbdps3kK8Ug5prUg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal to allow setting cursor options on Portals  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal to allow setting cursor options on Portals
Список pgsql-hackers


On Thu, 8 Jan 2026 at 14:22, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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


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

В списке pgsql-hackers по дате отправления: