On Sun, 14 Dec 2025 at 14:49, Dave Cramer <[email protected]> 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, 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.
