On Sun, 14 Dec 2025 at 09:04, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
On Sun, 14 Dec 2025 at 14:49, Dave Cramer <davecramer@gmail.com> wrote: > 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.
I agree drivers would like binary results back, but it's unclear to me how CURSOR_OPT_BINARY is different from setting the result column format codes to an array of a single 1? That should also change all columns to be binary right?
Fair point.
> 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.
I get what you mean, but I feel like we should at least be concerned with popular ecosystem tools like, pgbouncer and pgpool. But then it quickly becomes an exercise in where we draw the line, what about postgres forks like Yugabyte? Or things very similar like cockroachdb. Both of those are distributed, and probably don't use our LSNs. So as a concrete example, if we add LSNs to the protocol, it would be nice to work with their version too if it's not too much effort. e.g. by specifing a length for the commit id in the protocol instead of forcing it at the protocol level to always be a 64bit integer.
It would make sense to be forward looking here in the event that Postgres ever has wider LSN's agreed.
