| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Support named (destination) portals in extended proto for psql meta commands. |
| Date: | 2025-12-17 21:39:49 |
| Message-ID: | CAA5RZ0vdD33FsHQzWwGquE4q0HdLxa1gvRxKv1NOm-CPME2zsw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | GRANT ZHOU | 2025-12-17 21:43:31 | Re: Improve logical replication usability when tables lack primary keys |
| Previous Message | Zsolt Parragi | 2025-12-17 21:32:56 | Re: Add sanity check for duplicate enum values in GUC definitions |