From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
Cc: | "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)fr>, "PostgreSQL Developers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Variable substitution in psql backtick expansion |
Date: | 2017-04-03 14:16:18 |
Message-ID: | 12587.1491228978@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Daniel Verite" <daniel(at)manitou-mail(dot)org> writes:
> Let's imagine that psql would support a syntax like this:
> \if [select current_setting('server_version_num')::int < 110000]
> or
> \if [select 1 from pg_catalog.pg_extension where extname='pgcrypto']
I really dislike this syntax proposal. It would get us into having
to count nested brackets, and distinguish quoted from unquoted brackets,
and so on ... and for what? It's not really better than
\if sql select 1 from pg_catalog.pg_extension where extname='pgcrypto'
(ie, "\if sql ...text to send to server...").
If you're worried about shaving keystrokes, make the "select" be implicit.
That would be particularly convenient for the common case where you're
just trying to evaluate a boolean expression with no table reference.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2017-04-03 14:31:59 | Re: Statement timeout behavior in extended queries |
Previous Message | Tom Lane | 2017-04-03 14:05:16 | Re: Statement timeout behavior in extended queries |