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
