Re: Variable substitution in psql backtick expansion

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Variable substitution in psql backtick expansion
Дата
Msg-id 23763.1491177311@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Variable substitution in psql backtick expansion
Список pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>>> - how desirable/useful is it to have this in 10?

>> Extensions and extension-ish packages will love the _NUM vars.

> Hmmmm. I'm afraid pg extension scripts (for CREATE EXTENSION) are not 
> executed through psql, but server side directly, so there is not much 
> backslash-command support.

Yeah.

>> There's a lesser need for the _NAME vars.

> I put them more for error reporting, eg:

>    \if :VERSION_NUM < 110000
>      \echo :VERSION_NAME is not supported, should be at least 11.0
>      \q
>    \endif

I kinda feel like we're getting ahead of ourselves here, in that
the above is not going to do what you want until we have some kind
of expression eval capability built into psql.  You pointed out that
"\if false" can be used to reject pre-v10 psqls, but what about
rejecting v10?  ISTM that if we leave this out until there's something
that can do something useful with it, then something along the lines of

\if false -- pre-v10, complain and die
\endif
\if not defined VERSION_NUM -- pre-v11, complain and die
\endif

would do the trick.  Of course, there are probably other ways to
do that, but my point is that you haven't made a case why we need
to put this in now rather than later.
        regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: WIP: Covering + unique indexes.
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Fix obsolete comment in GetSnapshotData