On Sun, 7 Dec 2025 at 15:38, Dave Cramer <[email protected]> wrote: > My main driver here is to allow the creation of Holdable portals at the > protocol level for drivers.
Overall seems like a sensible feature to want. A somewhat random collection of thoughts: 1. We still have fairly limited experience with protocol options, so afaik not everyone agrees what we should use a version bump for vs a protocol extension. 2. I think I like the idea of optional fields that a client can add to the existing messages. That way "implementing" the new protocol version is a no-op for clients. 3. I think we should mark optional fields more clearly in the docs somehow. e.g. Make the docs say <term>Optional Int32</term> and explain what Optional means in the "Message Data Types" section. 4. I think the server should be strict that it only receives this optional field for the expected protocol version. 5. Do we really need to add the CURSOR_BINARY flag? Seems confusing with our other way of indicating binary support, i.e. what does it mean to say text as the format code but then specify CURSOR_BINARY. 6. What is the benefit of PQsendQueryPreparedWithCursorOptions? I understand the use case for PQsendBindWithCursorOptions, but not for PQsendQueryPreparedWithCursorOptions. 7. The server should check that no unknown flags are passed 8. Docs need to be added for the new libpq function(s) I have one question about your intended usage: I expect you intend to make using this opt-in for the users of pgjdbc? (i.e. by using some flag/different method to use this HOLD behaviour)
