Thread

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

Sami Imseih <samimseih@gmail.com> — 2025-12-13T13:48:20Z

Hi,

Thanks for raising this!

> I am a big fan of psql extended proto meta commands feature [0], and I
> frequently use these psql commands for testing purposes while
> developing [1] & [2].

+1

> Recently I had to support and test some more named portals (cursor)
> use-cases for [1]. And I faced a problem, that there is no way to test
> extended query bind commands for non-empty destination portal.

Same here [0], I ended up using JDBC to test my scenario for named
portals, but could not add in-core tests.

> So, I propose to add a psql meta command just for that purpose. Something
> like \bind_cursor CURSOR_NAME STMT_NAME [params..]

I like this idea, although instead of \bind_cursor ( or \bind_portal) what about
allowing a \portal to be optionally supplied to the end of a \bind_named?
This is easier to rationalize IMO because adding \bind_portal while we
have \bind_named is confusing.
If the \portal is not supplied, then an unnamed portal is used (current state),
and if it's supplied a named portal is used. Also, with this syntax we can allow
for a max_rows to be supplied to the portal, if we don't want to fetch
the portal
to completion.

```
\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
```

[0] https://www.postgresql.org/message-id/CAA5RZ0s-JLjD4E7shD9otcqJTgy-1K7FLrs9F%3D0QCC5qn_bMrQ%40mail.gmail.com

--
Sami Imseih
Amazon Web Services (AWS)