Re: proposal - assign result of query to psql variable

2012/10/15 Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>:
> Hi Pavel,
>
> First of all, I'm sorry that my previous review was rough. I looked
> your patch and existing code closely again.
>
> On 2012/10/15, at 12:57, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2012/10/14 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> * ExecQueryUsingCursor's concept of how to process command results
>>> (why? surely we don't need \gset to use a cursor)
>>
>> There was two possibilities, but hardly non using cursor is better way
>
> +1 for supporting the case when FETCH_COUNT > 0, because user might set
> so mainly for other queries, and they would want to avoid changing
> FETCH_COUNT setting during every query followed by \gset.
>
>>> * the psql lexer (adding a whole bunch of stuff that probably doesn't
>>> belong there)
>>
>> ??
>
> I think that Tom is talking about psql_scan_slash_vars(). It seems too
> specific to \gset command. How about to improve
> psql_scan_slash_options() so that it can handle comma-separated variable
> list? Although you might have tried it before.
> # Unused OT_VARLIST macro gave me the idea.

yes, it is possible - I'll look on it at evening

>
>>> * the core psql settings construct (to store something that is in
>>> no way a persistent setting)
>>>
>>
>> ??
>
> I thought that having \gset arguments in pset is reasonable, since \g
> uses pest.gfname to hold its one-shot setting. Or, we should refactor
> \g to fit with \gset? I might be missing Tom's point...
>
>>> Surely there is a less ugly and invasive way to do this. The fact
>>> that the reviewer keeps finding bizarre bugs like "another backslash
>>> command on the same line doesn't work" seems to me to be a good
>>> indication that this is touching things it shouldn't.
>>
>> - all these bugs are based on lexer construct. A little modification
>> of lexer is possible
>
> IMHO those issues come from the design rather than the implementation of
> lexer. AFAIK we don't have consensus about the case that both of \g and
> \gset are used for a query like this:
>
> postgres=# SELECT 1 \gset var \\ \g foo.txt
>
> This seems regal. Should we store "1" into var and write the result
> into foo.txt? Or, only either of them? It's just an idea and it
> requires new special character, but how about use \g command for file,
> pipe, and variable? In the case we choose '&' for variable prefix:
>
> postgres=# SELECT 'hello', 'wonderful', 'world!' \g &var1,,var2
>
> Anyway, we've had no psql's meta command which processes query result
> other than \g. So, we might have more considerable issues about design.

a current design is rigid - a small implementation can stop parsing
target list, when other backslash statement is detected

>
> BTW, what the word "comma_expected" means? It's in the comment above
> psql_scan_slash_vars(). It might be a remaining of old implementation.

This identifier is mistaken - etc this comment is wrong and related to
old implementation - sorry. A first design was replaced by state
machine described by VarListParserState

>
> Regards,
> --
> Shigeru HANADA
> shigeru(dot)hanada(at)gmail(dot)com
>
>
>
>
>