On Sun, 14 Dec 2025 at 09:04, Jelte Fennema-Nio <[email protected]> wrote:
> 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 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. Dave
