Re: Proposal to allow setting cursor options on Portals
| От | Jelte Fennema-Nio |
|---|---|
| Тема | Re: Proposal to allow setting cursor options on Portals |
| Дата | |
| Msg-id | CAGECzQQriv-h_h8Ygxh_RfnLt2G4P9nWrpgMi9YL2bmcOLbUEA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal to allow setting cursor options on Portals (Dave Cramer <davecramer@gmail.com>) |
| Ответы |
Re: Proposal to allow setting cursor options on Portals
|
| Список | pgsql-hackers |
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, but from my POV, we are only concerned with Postgres. I would say it's up to the other implementations to deal withincompatibilities. 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.
В списке pgsql-hackers по дате отправления: