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. >> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers