MIME-Version: 1.0
References: 
 <CADK3HHKe1PA1U6aB5-7tWBQ0yZGgNvY7H=ECDD9955Pas_zx_Q@mail.gmail.com>
 <CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
 <CAOYmi+nVQRpSs3vd_v9L8ytO9wnL2ndnzGwU31aDGorVFxrAYA@mail.gmail.com>
 <CAGECzQSZ43JMjA8QEJoF9DCdTO0GQeR2qyhouQciSG2ik40Yhg@mail.gmail.com>
 <CAOYmi+m20jS8zZ2qFpSnvhaqGDX+vtgCsqcu9VhokyLqF8kFag@mail.gmail.com>
 <CADK3HH+DPY_x_H=e0c_AVWoUP9E+YXdyJDVvmzYEYxZXT87Agw@mail.gmail.com>
 <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com>
 <CADK3HHKDrnRAoAcUv1ucLB0o_ZUcJRwm+jonNPNUHoDtcA9Crw@mail.gmail.com>
 <CAGECzQQriv-h_h8Ygxh_RfnLt2G4P9nWrpgMi9YL2bmcOLbUEA@mail.gmail.com>
 <CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@mail.gmail.com>
 <CADK3HH+o9dTYsXpCk7-Z0JW-QB2TV7=e97O8B-XDOGQb14AfSQ@mail.gmail.com>
 <CAOYmi+kkTbuwGa9X=XomNivAw9P4hN3M1U7QXiP7Jw+nrQXtNQ@mail.gmail.com>
 <CAGECzQSfCPXdOpUKfdkPA9iZhGyRjZAad-CXbhApZ2CnjgG2kw@mail.gmail.com>
 <CAOYmi+=qE1khrtTD7oQVPJQTHoXffQQ0DPHOx870r7801zhw9g@mail.gmail.com>
 <2155281.1767900170@sss.pgh.pa.us>
 <CADK3HH+6MTrMBsW+iDJ0VGzu7HQKJLLQbjnbdps3kK8Ug5prUg@mail.gmail.com>
 <CA+TgmoavFJW984Y8cUv-U9K+JqxYgqEj-i1A1dORwvyki5642A@mail.gmail.com>
 <CAGECzQSHKR2LtBSnDT_bjdpE1=cVzZLRcb2k5d_K=BMvJCFihg@mail.gmail.com>
 <431484.1768433414@sss.pgh.pa.us>
 <CADK3HH+TnNaW-b+d8xkUDcFZ-4oWhh5q3hCzbyuR9ShwMasHrA@mail.gmail.com>
 <CA+TgmoYr2RsE9OUwo42sxtpHr8gpdTtY6mGrWBbzu2sdFf6s8A@mail.gmail.com>
 <CADK3HHJ6TqYHgctgOTbuLJNHiKm5i_UE--goMKbcG7+5g2-fpQ@mail.gmail.com>
 <CAMT0RQRFa43CAf773LaDUvBYmZtwcNfdQSAzpBUtdJ+EiHH=kQ@mail.gmail.com>
 <CADK3HHKO0jXxj+r5f=qLJG-L20w0kw6mm9rR0dvUStwqiM+zkA@mail.gmail.com>
 <CADK3HHLvsPbz3e=1=N3TSYoB6B-d6AM3nUFK-SvWJSzfysKxrA@mail.gmail.com>
 <CADK3HH+Vef1fWVYj3eH0YnCVgHcWX981UA=Y4k0jCKjwVg-1PA@mail.gmail.com>
 <CADK3HHJHGPrzWpwmVPErq9XOcdg8nue-gPfoSz_=kabiKoZCOg@mail.gmail.com>
 <CAA5RZ0u=M0u1FHu1bFxYUoFCON=8OiQamdEnAH4-EJNDbYH7Xg@mail.gmail.com>
 <CAA5RZ0uESzrmA5zwHC=Uye2aH9_jHfHX7qAJPgUh8s_JLLn7PA@mail.gmail.com>
 <CADK3HH+JtK=-EDO0RzWjD5aV-Wa+DG991at=vmQa08KY6YY1Dg@mail.gmail.com>
 <CAA5RZ0v8LeJ7NG8K+A2O8d3eCw=1-gndzTwiQDpW3SmDPNJpDg@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0v8LeJ7NG8K+A2O8d3eCw=1-gndzTwiQDpW3SmDPNJpDg@mail.gmail.com>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Wed, 25 Mar 2026 08:27:05 +0100
Message-ID: 
 <CAGECzQR1Ez2VVp2a-++EbCWFdxt-iALtzm4uYe6_EDhtgfyTJg@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Sami Imseih <samimseih@gmail.com>
Cc: Dave Cramer <davecramer@gmail.com>, Hannu Krosing <hannuk@google.com>,
	Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Jacob Champion <jacob.champion@enterprisedb.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAGECzQR1Ez2VVp2a-%2B%2BEbCWFdxt-iALtzm4uYe6_EDhtgfyTJg%40mail.gmail.com>
Precedence: bulk

On Tue, 24 Mar 2026 at 21:54, Sami Imseih <samimseih@gmail.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@jeltef.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)