From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: psql: Add command to use extended query protocol |
Date: | 2022-11-08 02:47:28 |
Message-ID: | CADkLM=eH2ahryC8S2q64nZdOvU6kBGAhjx-XEfuARxErdvVyYw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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;
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.
From | Date | Subject | |
---|---|---|---|
Next Message | wangw.fnst@fujitsu.com | 2022-11-08 03:04:33 | RE: Logical replication timeout problem |
Previous Message | Tom Lane | 2022-11-08 02:36:33 | Re: allow segment size to be set to < 1GiB |