Re: psql: Add command to use extended query protocol
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-08T02:47:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
psql: Add command to use extended query protocol
- 5b66de3433e2 16.0 landed
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.