Re: Support named (destination) portals in extended proto for psql meta commands. - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Support named (destination) portals in extended proto for psql meta commands.
Date
Msg-id CAA5RZ0vdD33FsHQzWwGquE4q0HdLxa1gvRxKv1NOm-CPME2zsw@mail.gmail.com
Whole thread Raw
In response to Re: Support named (destination) portals in extended proto for psql meta commands.  (Kirill Reshke <reshkekirill@gmail.com>)
List pgsql-hackers
> > \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)



pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: Add sanity check for duplicate enum values in GUC definitions
Next
From: GRANT ZHOU
Date:
Subject: Re: Improve logical replication usability when tables lack primary keys