From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>, "corey(dot)huinker" <corey(dot)huinker(at)gmail(dot)com> |
Subject: | Re: Variable substitution in psql backtick expansion |
Date: | 2017-04-11 07:07:44 |
Message-ID: | alpine.DEB.2.20.1704111558030.29476@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I think so implementation of simple expression evaluation should not be
> hard
Indeed it is not hard, it is rather a matter of deciding what it should
do, and the syntax to do it.
> - really just - we can expect so any variable will be replaced by
> const in expression
>
> Num (<|>|=|<=|>=) Num
<> and != would seem handy as well.
> Text (<|>|=|<=|>=) Text
What would be the use case for handling TEXT?
> not Bool, Bool (or|and) Bool
Aka logical expressions.
> and special operator "defined"
I'm still not buying this suggestion at all because it does not look like
SQL and I think that client-side expressions should be a simple subset of
SQL expressions, which a "defined" operators is definitely not.
>> Hmmm. I'm not sure I get it. The penalty I see is that it adds a dummy
>> variable which must be given a sensible name, and for very short
>> expressions this is not a win. But this is a minor point.
> I know so it is not ideal - but the language with commands "\if", "\else"
> ... is not ideal language.
Sure.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2017-04-11 07:11:47 | Re: strange parallel query behavior after OOM crashes |
Previous Message | Pavel Stehule | 2017-04-11 07:04:52 | Re: Variable substitution in psql backtick expansion |