ú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; I think so there should not be problem with custom strings, because we are able to push $x to stored procedures, so it should be safe to use it elsewhere We can use the syntax @var - that is used by pgadmin Regards Pavel > 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. > >
