út 8. 11. 2022 v 5:21 odesílatel David G. Johnston < david.g.johns...@gmail.com> napsal:
> On Mon, Nov 7, 2022 at 9:02 PM Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> >> >> út 8. 11. 2022 v 3:47 odesílatel Corey Huinker <corey.huin...@gmail.com> >> napsal: >> >>> On Mon, Nov 7, 2022 at 4:12 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >>> >>>> Corey Huinker <corey.huin...@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. >
