Re: Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Variable substitution in psql backtick expansion
Date
Msg-id 23763.1491177311@sss.pgh.pa.us
Whole thread Raw
In response to Re: Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: WIP: Covering + unique indexes.
Next
From: Craig Ringer
Date:
Subject: Re: Fix obsolete comment in GetSnapshotData