Re: psql: Add command to use extended query protocol
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Corey Huinker <corey.huinker@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-08T04:29:41Z
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
út 8. 11. 2022 v 5:21 odesílatel David G. Johnston < david.g.johnston@gmail.com> napsal: > On Mon, Nov 7, 2022 at 9:02 PM Pavel Stehule <pavel.stehule@gmail.com> > wrote: > >> >> >> ú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; >> > > Why not extend psql conventions for variable specification? > > SELECT :$var$; > > Thus: > :var => Ahoj > :'var' => 'Ahoj' > :"var" => "Ahoj" > :$var$ => $n (n => <Ahoj>) > > The downside is it looks like dollar-quoting but isn't actually causing > <$Ahoj$> to be produced. Instead psql would have to substitute $n at that > location and internally remember that for this query $1 is the contents of > var. > > I would keep the \gp meta-command to force extended mode regardless of > whether the query itself requires it. > > A pset variable to control the default seems reasonable as well. The > implication would be that if you set that pset variable there is no way to > have individual commands use simple query mode directly. > :$var$ looks little bit scary, and there can be risk of collision with custom string separator but :$var can be ok? There is not necessity of showing symmetry > > David J. >