On Tue, 24 Mar 2026 at 11:01, Dave Cramer <[email protected]> wrote: > _pq_.cursor would be fine.
I think that makes sense as a name for the option. I think adding flag support for SCROLL and NO SCROLL would make sense in that case. Some notes on the patch (but I didn't look look at the client side libpq code in detail): For the protocol definition I'd like a few changes: 1. I'd like the new field in the bind message that you add to be described as an extension bitmap, not specifically for cursor options, so that future extensions could add bits too it too. 2. Related to that, I think the used bits should not align with the internal bits. Having the only valid flag bit be 0x0020 is kinda weird. Let's just make that 0x0001. We could update the internal ones to match if desired, but I think it's fine for the protocol bits to differ from the bits in the postgres server. Docs still mention CURSOR_OPT_BINARY, but support for that has been removed from the code afaict (which I think is indeed what should happen) There's a bunch of protocol version 3.3 code still around, which should be removed now that the protocol option is added. PQsendBindWithCursorOptions and PQsendQueryPreparedWithCursorOptions should error out if conn->holdable_portal_enabled is false. Right now it silently skips the cursor options if the connection does not support the protocol extension. There should be a libpq function to inspect whether the connection supports cursor options, so some kind of graceful fallback logic can be implemented by the application when it's not supported. libpq docs are missing
