Re: psql: Add command to use extended query protocol - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: psql: Add command to use extended query protocol
Date
Msg-id CADkLM=eH2ahryC8S2q64nZdOvU6kBGAhjx-XEfuARxErdvVyYw@mail.gmail.com
Whole thread Raw
In response to Re: psql: Add command to use extended query protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: psql: Add command to use extended query protocol
List pgsql-hackers
On Mon, Nov 7, 2022 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Corey Huinker <corey.huinker@gmail.com> writes:
> I thought about basically reserving the \$[0-9]+ space as bind variables,
> but it is possible, though unlikely, that users have been naming their
> variables like that.

Don't we already reserve that syntax as Params?  Not sure whether there
would be any conflicts versus Params, but these are definitely not legal
as SQL identifiers.

                        regards, tom lane

I think Pavel was hinting at something like:

\set $1 foo
\set $2 123
UPDATE mytable SET value = $1 WHERE id = $2;

Which wouldn't step on anything, because I tested it, and \set $1 foo already returns 'Invalid variable name "$1"'.

So far, there seem to be two possible variations on how to go about this:

1. Have special variables or a variable namespace that are known to be bind variables. So long as one of them is defined, queries are sent using extended query protocol.
2. Bind parameters one-time-use, applied strictly to the query currently in the buffer in positional order, and once that query is run their association with being binds is gone.

Each has its merits, I guess it comes down to how much we expect users to want to re-use some or all the bind params of the previous query.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: allow segment size to be set to < 1GiB
Next
From: "wangw.fnst@fujitsu.com"
Date:
Subject: RE: Logical replication timeout problem