Re: Proposal to allow setting cursor options on Portals

On Wed, 25 Mar 2026 at 15:34, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
> Attached is v4 of the patch
> Co-Authored by Sami Imseih
>
> Adds docs and test module

It's looking much more finished

> The portal can
> later be operated on with cursor commands such as FETCH, MOVE,
> and CLOSE.

This made me realize that, adding the Bind side of cursors is only
half of the equation. The "Execute" message should also gain new
behaviour to support all the same functionality as FETCH and MOVE. I
think we can do that fairly easily by adding similar flags to Execute.
I think we'd need three flags:
1. MOVE
2. BACKWARD
3. ABSOLUTE

I do realize the scope creep of this, but it feels that without
addressing Execute we have a half-finished feature. That could be
fine, but then I don't think we should call the option
_pq_.protocol_cursor. Because that sounds like it solves the whole
half-baked protocol-level cursor implemention that we currently have.
Maybe _pq_.cursor_bind instead.

I think the "protocol_" part in _pq_.protocol_cursor is duplicative.
The _pq_ part already indicates that it's a protocol option, so I'd
leave that out.

> <symbol>PQ_BIND_CURSOR_SCROLL</symbol> (scroll),
> <symbol>PQ_BIND_CURSOR_NO_SCROLL</symbol> (no scroll), and
> <symbol>PQ_BIND_CURSOR_HOLD</symbol> (hold).
> These are defined in <filename>libpq-fe.h</filename>.

and

> <para>
> Bitmap set by protocol extensions.
> </para>

I think the Message Formats page should list the actual flag values
that are valid. The protocol docs should not require you to look at
the postgres source code.

/*
* Only override the default cursorOptions when the client has
* explicitly set flags. A value of 0 means no cursor options were
* requested, so keep the CreatePortal defaults.
*/

What is the difference between setting cursorOptions = 0 and the
CreatePortal defaults?

> {"protocol_cursor", NULL, "0", NULL,
> "Protocol-Cursor", "", 1,
> offsetof(struct pg_conn, protocol_cursor)},

In my GoAway patchset I linked enabling the protocol extension to the
user requesting protocol v3.2 (or higher).

> /* Reject any bits we don't recognize */
> if (bind_ext_flags & ~0x0007)

Let's use PQ_BIND_CURSOR_VALID_FLAGS here too instead of this magic number.

> src/test/modules/libpq_protocol_cursor/libpq_protocol_cursor.c

I think it'd be better to put these tests in the libpq_pipeline test
file. Then we can keep all the libpq tests together so they can share
the helper logic.