Re: proposal - assign result of query to psql variable

2012/10/25 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> I gave this a look. I think it needs to be revised by somebody with a
>> better understanding of scanner (flex) than me, but I didn't like the
>> changes in psqlscan.l at all; the new <xvl> pattern is too unlike the
>> rest of the surrounding patterns, and furthermore it has been placed
>> within the block that says it mirrors the backend scanner, when it
>> obviously has no equivalent there.
>
>> I assume there's a better way to do this. Hints would be appreciated.
>
> Personally I saw no reason for this patch to touch psqlscan.l in the
> first place. Commands such as \set just scan variable names with
> psql_scan_slash_option(OT_NORMAL); why shouldn't this act the same?
>

it cannot be same, because current scan doesn't know comma as
separator. So if you don't like changes in scanner, than we can't to
use "var1, var2," syntax and we can't to use leaky list syntax ",x,"

> Moreover, the proposed lexer rules are flat out *wrong*, in that they
> insist on the target variable names being {identifier}s, a restriction
> not imposed by \set.
>

do you like to support referenced varnames??

postgres=# \varname xxx
Invalid command \varname. Try \? for help.
postgres=# \set varname xxx
postgres=# \set :varname Hello
postgres=# \set
varname = 'xxx'
xxx = 'Hello'

yes, \set support it, but this can be source of "strange behave" for
some people, because people use :varname like $varname in classic
scripting languages, and it is significantly different - so I didn't
support it as little bit dangerous feature. It is easy support it,
although I am thinking, so it is not good idea, because behave is
really different than users expect and I don't know any use case for
this indirect referencing. But I would to talk about it, and I invite
opinion of others.

Regards

Pavel

> regards, tom lane