Re: [HACKERS] Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] Variable substitution in psql backtick expansion
Date
Msg-id alpine.DEB.2.20.1704111558030.29476@lancre
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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.



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] Variable substitution in psql backtick expansion
Next
From: Kuntal Ghosh
Date:
Subject: Re: [HACKERS] strange parallel query behavior after OOM crashes