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 CAFj8pRAC7w_SUMQtUDibeOByXyMyCsPSPjWNfFx57YRfUKW5tA@mail.gmail.com
Whole thread Raw
In response to Re: proposal - assign result of query to psql variable  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
2012/10/15 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> 2012/10/14 Tom Lane <tgl@sss.pgh.pa.us>:
>> Pavel Stehule <pavel.stehule@gmail.com> writes:
>>> [ gset_08.diff ]
>>
>> In the course of adding a new backslash command, this patch manages to
>> touch:
>>
>> * the main loop's concept of what types of backslash commands exist
>>   (PSQL_CMD_NOSEND ... what's the point of that, rather than making
>>   this work the same as \g?)
>
> This is necessary, because there is a new possible state - "query is
> complete, but command is wrong" - so I cannot use \g implementation,
> because there is no possible error in \g or ';'
>
>> * SendQuery's concept of how to process command results (again, why
>>   isn't this more like \g?)
>
> it is similar - difference is only in work with result - \gset uses
> StoreQueryResult instead PrintQueryResults, but other is same
>
>
>> * ExecQueryUsingCursor's concept of how to process command results
>>   (why? surely we don't need \gset to use a cursor)
>
> It is my mistake - simply and correct way is not using cursor in this use case

and it is question if cursor support is bad decision, because cursors
can help with large queries, that can returns thousands rows - and we
can raise error early, before we fall on "out of memory"

regards

Pavel

>
>> * the psql lexer (adding a whole bunch of stuff that probably doesn't
>>   belong there)
>
> I had to modify lexer - current lexer supports symbols separated by
> space, but not symbols separated by comma. We don't would to use
> variable evaluation in target variable list.
>
>> * the core psql settings construct (to store something that is in
>>   no way a persistent setting)
>
> sorry, I don't understand to this issue
>
>>
>> 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.
>>
>
> I had too strong in checking and raising errors. Is relative simple to
> modify patch to enable more backslash statements on same line
>
> I'll send updated patch early
>
> Regards
>
> Pavel
>
>>                         regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal - assign result of query to psql variable
Next
From: Heikki Linnakangas
Date:
Subject: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown