Re: proposal - assign result of query to psql variable

Hello

here is updated patch, I moved lot of code from lexer to command.com,
and now more \gset doesn't disable other backslash commands on same
line.

Regards

Pavel

2012/10/15 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2012/10/15 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>> 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
>
> a reuse of psql_scan_slash_options is not good idea - a interface of
> this function is out of my purposes - and I cannot to signalise error
> from this procedure. But I can minimize psql_scan_slash_var and I can
> move lot of code out of lexer file.
>
>>
>>>
>>>>> * 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
>>>
>>>
>>>
>>>
>>>