Re: proposal - assign result of query to psql variable
От | Shigeru Hanada |
---|---|
Тема | Re: proposal - assign result of query to psql variable |
Дата | |
Msg-id | CAEZqfEdBvZQZLXbQyPrM6ct0f1srx-qGT-0KdfyF5HkiDFpcow@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal - assign result of query to psql variable (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal - assign result of query to psql variable
|
Список | pgsql-hackers |
On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > Hello > > here is updated patch > > main change - it doesn't touch psql lexer - like Tom proposed > other points respect Phil's notices I reviewed v12 patch. It provides gset command which works consistently with other psql commands, such as \g and \set, and implementation seems reasonable, and follows other reviewer's comments properly. I think we can mark it as "ready for committer", once you have fixed some minor issues below. * Skipping leading blank in inner while loop of command.c seems unnecessary, because (IIUC) psql's scanner skips blanks. Is there any case that scanner returns token with leading/trailing blank? * ISTM that VARLIST_INITIAL can be removed. AFAIS it's same state as VARLIST_EXPECTED_COMMA_OR_IDENT. * I found some cosmetic flaw and typo. Please see attached patch for details. * How about pulling up codes for PGRES_TUPLES_OK case in StoreQueryResult to new static function, say StoreQueryTuple? It would make StoreQueryResult more similar to PrintQueryResult's style, and IMO it makes the code more readable. Regards, -- Shigeru HANADA
Вложения
В списке pgsql-hackers по дате отправления: