On Tue, 24 Mar 2026 at 21:54, Sami Imseih <[email protected]> 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 <[email protected]> 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)
