| From: | Dave Cramer <davecramer(at)gmail(dot)com> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Proposal to allow setting cursor options on Portals |
| Date: | 2025-12-15 11:32:18 |
| Message-ID: | CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 14 Dec 2025 at 09:04, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> On Sun, 14 Dec 2025 at 14:49, Dave Cramer <davecramer(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2025-12-15 11:41:06 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Álvaro Herrera | 2025-12-15 11:30:58 | Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY |