Re: psql: Add command to use extended query protocol

út 8. 11. 2022 v 3:47 odesílatel Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
napsal:

> On Mon, Nov 7, 2022 at 4:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Corey Huinker <corey(dot)huinker(at)gmail(dot)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.
>
>