Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2012/10/25 Tom Lane <tgl@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.
>> 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.
regards, tom lane
