On Sun, 14 Dec 2025 at 08:42, Jelte Fennema-Nio <[email protected]> wrote:
> 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]. > Here I was thinking that binary was the one that did make sense. The pgjdbc driver would like the results back in binary, I believe others would as well. > 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. > Fair, but from my POV, we are only concerned with Postgres. I would say it's up to the other implementations to deal with incompatibilities. Dave
