Re: proposal - assign result of query to psql variable
От | Pavel Stehule |
---|---|
Тема | Re: proposal - assign result of query to psql variable |
Дата | |
Msg-id | CAFj8pRDrhDVj=NpBF_gKKcwd-k3sFE6gUjL-ts_hLuimywZJjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal - assign result of query to psql variable (Shigeru Hanada <shigeru.hanada@gmail.com>) |
Ответы |
Re: proposal - assign result of query to psql variable
Re: proposal - assign result of query to psql variable |
Список | pgsql-hackers |
2012/12/17 Shigeru Hanada <shigeru.hanada@gmail.com>: > 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? removed > * ISTM that VARLIST_INITIAL can be removed. AFAIS it's same state as > VARLIST_EXPECTED_COMMA_OR_IDENT. removed > * I found some cosmetic flaw and typo. Please see attached patch for details. it is ok, merged > * 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. good idea done Attached updated patch Regards Pavel > > Regards, > -- > Shigeru HANADA
Вложения
В списке pgsql-hackers по дате отправления: