public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jelte Fennema-Nio <[email protected]>
To: Dave Cramer <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Subject: Re: Proposal to allow setting cursor options on Portals
Date: Sun, 14 Dec 2025 14:41:53 +0100
Message-ID: <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com> (raw)
In-Reply-To: <CADK3HH+DPY_x_H=e0c_AVWoUP9E+YXdyJDVvmzYEYxZXT87Agw@mail.gmail.com>
References: <CADK3HHKe1PA1U6aB5-7tWBQ0yZGgNvY7H=ECDD9955Pas_zx_Q@mail.gmail.com>
<CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
<CAOYmi+nVQRpSs3vd_v9L8ytO9wnL2ndnzGwU31aDGorVFxrAYA@mail.gmail.com>
<CAGECzQSZ43JMjA8QEJoF9DCdTO0GQeR2qyhouQciSG2ik40Yhg@mail.gmail.com>
<CAOYmi+m20jS8zZ2qFpSnvhaqGDX+vtgCsqcu9VhokyLqF8kFag@mail.gmail.com>
<CADK3HH+DPY_x_H=e0c_AVWoUP9E+YXdyJDVvmzYEYxZXT87Agw@mail.gmail.com>
On Sun, 14 Dec 2025 at 13:31, Dave Cramer <[email protected]> wrote:
>> Exactly. Don't you want to make sure that clients in the ecosystem are
>> able to use this _before_ we rev the version again, and again? We
>> don't ever get these numbers back.
>
> Well there are 97 of them. 1 per year is a long time.
I don't think Jacob was concerned about the actual numbers running
out, but in case he was: it's actually 9997 versions that we still
have (9996 after we'd commit the grease proposal[1]).
[1]: https://commitfest.postgresql.org/patch/6157/
> FWIW, HOLDABLE cursors are not the only option this enables. It enables all of the other cursor options.
As mentioned upthread, I'm not sure BINARY makes sense. For any other
options, the protocol docs should specify which ones are allowed and
what their bits are. Looking at the DECLARE docs[2].
1. I think supporting ASENSITVE/INSENSITIVE/SENSITIVE bits is
unnecessary, since postgres cursors are always INSENSITIVE.
2. For SCROLL vs NO SCROLL, it would be nice if we could get rid of
the intermediate mode where if neither SCROLL or NO SCROLL is
specified, it's still SCROLL sometimes. I'm not sure backwards
compatibility would allow that, i.e. can you currently sometimes do a
BACKWARD scan on a portal created with Bind. I guess we could make it
so that if you specify the portal flags, then you have to be explicit
abuot specifying SCROLL or NO SCROLL
3. All the flags with no SQL variant probably shouldn't be
configurable through the protocol too (e.g. CURSOR_OPT_FAST_PLAN)
[2]: https://www.postgresql.org/docs/18/sql-declare.html
> Are we concerned with servers that are not compatible with Postgres ?
I think there's enough re-implementations of the postgres protocol by
other databases that it would be a shame if we didn't even try to
consider them, but I wouldn't consider it critical to get it right.
Since they can always throw application errors for features they don't
support, just like they do now for SQL that they don't support. They
can always contribute changes to clients to make using unsupported
features opt-in in the rare case where they are not.
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Proposal to allow setting cursor options on Portals
In-Reply-To: <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox