Thread

  1. Re: Support named (destination) portals in extended proto for psql meta commands.

    Sami Imseih <samimseih@gmail.com> — 2025-12-17T21:39:49Z

    > > \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.
    
    cool!
    
    > 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)?
    
    We will need a new function called `PQsendQueryPreparedPortal` or something
    like that, which takes in a portal name. `PQsendQueryGuts` will need
    to be modified
    to take in a portal name, but being a local function, that will not
    break libpq ABI.
    
    > 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?
    
    I think it will be good to have a \close_cursor. I think \close_portal will
    be better since a SQL-level cursor is just one way to create a named
    portal.
    
    It will be good, IMO, to roll this out with everything else to have
    feature parity
    with \close_prepared.
    
    --
    Sami Imseih
    Amazon Web Services (AWS)