Re: Proposal to allow setting cursor options on Portals
| От | Dave Cramer |
|---|---|
| Тема | Re: Proposal to allow setting cursor options on Portals |
| Дата | |
| Msg-id | CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal to allow setting cursor options on Portals (Jelte Fennema-Nio <postgres@jeltef.nl>) |
| Список | pgsql-hackers |
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.
Dave
В списке pgsql-hackers по дате отправления: