Re: Variable substitution in psql backtick expansion

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
Date: 2017-04-02 23:55:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
> \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
\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

In response to


Browse pgsql-hackers by date

  From Date Subject
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.