Sami, Jelte, thank you for looking into this. On Sat, 13 Dec 2025 at 18:48, Sami Imseih <[email protected]> wrote:
> > ``` > \portal name [max_rows] > > -- prepare the statements > select from mytab limit $1 \parse p1 > > -- bind/execute the statement, optionally to a portal > \bind_named p1 10 \portal portalname \g > \bind_named p1 50 \portal portalname \g > > -- bind/execute the statement, optionally to a portal, with max_rows > \bind_named p1 50 \portal portalname 50 \g > \bind_named p1 50 \portal portalname 40 \g > ``` > > The syntax may seem awkward, but we already do this with \bind, > where the meta command is not at the start. > > ``` > select $ \bind 1 \g > ``` The separate "\portal" command is the design I actually find surprisingly simple and pretty. So, that's what I have implemented in v1-0002. I am now posting some WIP versions of changes. v1-0001 still needs some comprehensive changes to the doc, but I decided to already post something to this thread. Another concern is changing the ABI of libpq. v1-0001 changes the number of `PQsendQueryPrepared` parameters, and this is something that has not been changed for 20+ years... Maybe the better choice would be a new, separate function (which will still be just a proxy-function to PQsendQueryGuts)? Also, I think that we need to support closing destination portals using psql meta-commands. The current design in my head is a separate "'\close_cursor <name>" command. Since we still can cancel a portal using SQL-level command (CLOSE), I think this should be separate patches to the series. WHYT? -- Best regards, Kirill Reshke
v1-0002-Support-portal-meta-command-in-psql.patch
Description: Binary data
v1-0001-Add-destincation-portal-parameter-to-libpq-interf.patch
Description: Binary data
