Re: proposal - assign result of query to psql variable

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal - assign result of query to psql variable
Дата
Msg-id CAFj8pRAC7w_SUMQtUDibeOByXyMyCsPSPjWNfFx57YRfUKW5tA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal - assign result of query to psql variable  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: proposal - assign result of query to psql variable
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown