Re: psql: Add command to use extended query protocol

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: psql: Add command to use extended query protocol
Дата
Msg-id CAFj8pRDFK9u1WLnffmbS4HLSCShXeZBjsmY=oWRwXNxT5Z3n=w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: psql: Add command to use extended query protocol  (Corey Huinker <corey.huinker@gmail.com>)
Ответы Re: psql: Add command to use extended query protocol
Список pgsql-hackers


út 8. 11. 2022 v 3:47 odesílatel Corey Huinker <corey.huinker@gmail.com> napsal:
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;

no, I just proposed special syntax for variable usage like bind variable

like

\set var Ahoj

SELECT $var;

I think so there should not be problem with custom strings, because we are able to push $x to stored procedures, so it should be safe to use it elsewhere

We can use the syntax @var - that is used by pgadmin

Regards

Pavel




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 по дате отправления:

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Perform streaming logical transactions by background workers and parallel apply
Следующее
От: Ajin Cherian
Дата:
Сообщение: Re: Support logical replication of DDLs