Re: Variable substitution in psql backtick expansion

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.

In response to

Responses

Browse pgsql-hackers by date

  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