|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|Cc:||Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Variable substitution in psql backtick expansion|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>> 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
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
-- pre-v10, complain and die
\if not defined VERSION_NUM
-- pre-v11, complain and die
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
|Next Message||Craig Ringer||2017-04-03 01:29:29||Re: Fix obsolete comment in GetSnapshotData|
|Previous Message||Peter Geoghegan||2017-04-02 23:44:40||Re: WIP: Covering + unique indexes.|