On Mon, Dec 8, 2025 at 4:43 PM Jelte Fennema-Nio <[email protected]> wrote:
> 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) Thx for the comments. Yes JDBC has a holdable resultset as a standard part of the API Dave > >
