Re: Proposal to allow setting cursor options on Portals

On Mon, 15 Dec 2025 at 06:32, Dave Cramer <davecramer(at)gmail(dot)com> wrote:

>
>
> 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.
>

Any progress on this ?

Dave

>