Re: Proposal to allow setting cursor options on Portals

On Tue, 24 Mar 2026 at 21:54, Sami Imseih <samimseih(at)gmail(dot)com> wrote:
> All the cursor options can be passed, though CURSOR_OPT_BINARY is
> irrelevant in the extended query protocol as noted here [1]. Binary output is
> controlled by the result format codes on the FETCH instead. So,
> CURSOR_OPT_BINARY can be passed as a cursor option, but will be
> silently ignored.

This is what this patch originally did in one of the earlier versions.
And if I understand correctly it was changed after this feedback from
me:

On Sun, 14 Dec 2025 at 14:41, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> As mentioned upthread, I'm not sure BINARY makes sense. For any other
> options, the protocol docs should specify which ones are allowed and
> what their bits are. Looking at the DECLARE docs[2].
> 1. I think supporting ASENSITVE/INSENSITIVE/SENSITIVE bits is
> unnecessary, since postgres cursors are always INSENSITIVE.
> 2. For SCROLL vs NO SCROLL, it would be nice if we could get rid of
> the intermediate mode where if neither SCROLL or NO SCROLL is
> specified, it's still SCROLL sometimes. I'm not sure backwards
> compatibility would allow that, i.e. can you currently sometimes do a
> BACKWARD scan on a portal created with Bind. I guess we could make it
> so that if you specify the portal flags, then you have to be explicit
> abuot specifying SCROLL or NO SCROLL
> 3. All the flags with no SQL variant probably shouldn't be
> configurable through the protocol too (e.g. CURSOR_OPT_FAST_PLAN)