Re: proposal - assign result of query to psql variable - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal - assign result of query to psql variable
Date
Msg-id CAFj8pRAk=5TYhb=swjYe5Ehxwv0_8cde8vVDw_uCjuCaA8b5sg@mail.gmail.com
Whole thread Raw
In response to Re: proposal - assign result of query to psql variable  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2012/10/25 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal - assign result of query to psql variable
Next
From: Jesper Krogh
Date:
Subject: Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation