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.stehule@gmail.com> wrote:
> 2012/10/14 Tom Lane <tgl@sss.pgh.pa.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.
>> * 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.
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.
Regards,
--
Shigeru HANADA
shigeru.hanada@gmail.com
