Re: proposal - assign result of query to psql variable

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal - assign result of query to psql variable
Дата
Msg-id 19992.1359218557@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal - assign result of query to psql variable  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal - assign result of query to psql variable  (Andrew Dunstan <andrew@dunslane.net>)
Re: proposal - assign result of query to psql variable  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
I wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> [ gset_13.diff ]

> One more gripe is that the parsing logic for \gset is pretty
> unintelligible.

After further thought, it seems to me that the problem here is an
overcomplicated definition of the \gset command; it could be made
both more usable and simpler to implement, if we looked at it
differently.

First off, why is there a provision to omit variable names for some
columns, ie why bother with saying that you can write \gset x,,y to
store only the first and third columns?  If you didn't want the second
value, why didn't you leave it out of the SELECT to start with?
It seems like the only possible reason for that is if you were lazy
and typed "SELECT *" instead of listing the columns ... but then you
still need to list the columns in \gset, and it's pretty error-prone
to make sure that the \gset variable list lines up with what "*" will
emit.

In fact, it's pretty error-prone to have to make the \gset variable list
line up with the SELECT columns in any case.  So here's my proposal:
let's forget the variable list entirely, and use the column names
returned by the server as the variable names to assign to.  So instead
ofselect 1, 2 \gset x,y
you would writeselect 1 as x, 2 as y \gset
or justselect 1 x, 2 y \gset
which is exactly as much typing as the existing definition, but much
harder to screw up by misaligning the SELECT's values with the target
names.  It also makes it really trivial to do the "SELECT *" case ---
you just do it, and ignore any variables for columns you don't care
about.

A probably-useful extension to this basic concept is to allow \gset
to specify an optional prefix, that isselect 1 as x, 2 as y \gset p_
would set p_x and p_y.  This would make it easier to manage results from
multiple \gset operations, and to be sure that you didn't accidentally
overwrite some built-in variable.

So this seems to me to be easier and less error-prone to use than the
existing definition.  It would also take a lot less code to implement,
since the parsing logic for \gset would reduce to a couple of lines,
and you'd not need the variable-name-list data structure at all.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Phil Sorber
Дата:
Сообщение: Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)