2012/10/25 Tom Lane <t...@sss.pgh.pa.us>:
> Pavel Stehule <pavel.steh...@gmail.com> writes:
>> 2012/10/25 Tom Lane <t...@sss.pgh.pa.us>:
>>> 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,"
>
> Uh, no, that doesn't follow. It wouldn't be any more code to have
> command.c process the commas (or even more likely, just save the \gset
> argument(s) as a string, and split on commas after we've done the
> command). Even if we wanted to do that in psqlscan.l, this was a pretty
> bad/ugly implementation of it.
I don't understand, why we have to move lexer work from scanner to
command processing?
then I afraid of another issue - when we do late separation in command
somebody can do
\set targetvars a,b,c
select xxxx
\gset x1,x2,:targetvars,x3
We would to do this? Then we moving to TeX liked languages. I am asking.
>
>>> 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.
>
>> 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.
>
> [ shrug... ] If you want to argue for imposing a restriction on
> psql variable names across-the-board, we could have that discussion;
> but personally I've not seen even one user complaint that could be
> traced to \set's laxity in the matter, so I don't see a need for
> a restriction. In any case, having \gset enforce a restriction
> that \set doesn't is useless and inconsistent.
ok, it has a sense
>
> regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
