From: Fabien COELHO <coelho@cri.ensmp.fr>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Verite <daniel@manitou-mail.org>
Cc: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: Variable substitution in psql backtick expansion
Date: Tue, 4 Apr 2017 09:53:13 +0200 (CEST)
Message-ID: <alpine.DEB.2.20.1704040924430.31209@hendaye> (raw)
In-Reply-To: <CAFj8pRAOZvoO4gVS1uioo1eUE7+EmzfdkdacQsejMrPHwZZrog@mail.gmail.com>
References: <ae3900f7-3064-4d4c-8e9d-673ac8bbb911@manitou-mail.org>
<12587.1491228978@sss.pgh.pa.us>
<alpine.DEB.2.20.1704032118250.23892@lancre>
<CAFj8pRAOZvoO4gVS1uioo1eUE7+EmzfdkdacQsejMrPHwZZrog@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hello Pavel,
> The expression evaluation is interesting question, but there is a
> workaround - we can use \gset already.
Yes, that is a good point. It is a little bit inconvenient because it
requires a dummy variable name each time for testing.
SELECT whatever AS somename \gset
\if :somename
But this is an already functional solution to use server-side expressions,
so there is no hurry.
> What is more important, because there is not any workaround, is detection
> if some variable exists or not.
>
> So possibilities
>
> 1. \if defined varname
Yep, and as Tom pointed it should handle NOT as well.
My issue with this version is that Lane Tom convinced me some time ago
that client side expressions should look like SQL expressions, so that
everything in the script is somehow in the same language. I think that he
made a good point.
However "defined varname" is definitely not an SQL expression, so I do not
find that "intuitive", for a given subjective idea of intuitive.
Then there is the question of simple comparisons, which would also make
sense client-side, eg simple things like:
\if :VERSION_NUM >= 110000
Should not need to be executed on the server.
> 2. \ifdefined or \ifdef varname
I think that we want to avoid that if possible, but it is a cpp-like
possibility. This approach does not allow to support comparisons.
> 3. \if :?varname
Tom suggested that there is a special namespace problem with this option.
I did not understand what is the actual issue.
> I like first two, and I can live with @3 - although it is not intuitive
For me @3 is neither worth nor better than the already existing :'varname'
and :"varname" hacks, it is consistent with them, so it is just an
extension of the existing approach.
It seems easy to implement because the substitution would be handled by
the lexer, so there is no need for anything special like looking at the
first or second word, rewinding, whatever.
Basically I agree with everything Tom suggested (indeed, some client side
definition & comparison tests are really needed), but not with the
proposed prefix syntax because it does not look clean and SQL.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: coelho@cri.ensmp.fr, pavel.stehule@gmail.com, tgl@sss.pgh.pa.us, daniel@manitou-mail.org
Subject: Re: Variable substitution in psql backtick expansion
In-Reply-To: <alpine.DEB.2.20.1704040924430.31209@hendaye>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox