Re: [HACKERS] Undefined psql variables - Mailing list pgsql-hackers

> I suggest to reuse pgbench expression engine, developed by Haas Robert:-)

Not a bad idea (though I'm sure there are other reasonable options, too).

I don't want to stand in the way of any progress in getting expressions into \if and some subspecies of \set. But, assuming we don't get it into v10, our documentations currently says this about expressions:

Expressions that do not properly evaluate to true or false will generate a warning and be treated as false.

We should probably amend that to say something about the potential future directions of expressions, perhaps this:

Expressions that do not properly evaluate to true or false will generate a warning and be treated as false, though that behavior is subject to change in future versions of psql.

That should guard us against people getting too attached to that behavior in the interim.

With that said, I'm starting to like the idea of not boxing ourselves into one type of expression. Maybe the first token could be the expression context with the expression to follow

The expression type we have now

\if true

"defined" is a context (or "mode") that expects one token that might be a psql varname

\if defined varname

"sql" is a context that treats the rest of the line as a SQL statement to the current connection, and looks at the first column of first row for "truth"

\if sql SELECT EXISTS(SELECT null FROM item WHERE manufacturer = 'Frobozz')

"pgbench" could invoke the pgbench expression engine.

\if pgbench <valid pgbench expression>

Anything else is treated as an external expression evaluator. If an expression has an unknown context "foo", check the ENV vars for EXPR_FOO, and pipe the remaining expression tokens to $PSQL_EXPR_FOO if it exists, and read the output of that for psql-boolean truth.  I think having a context/mode token could allow us to have lots of pluggable expression types with minimal effort to psql itself. 

"python" invokes a python interpreter (if PSQL_EXPR_PYTHON is defined, fails otherwise) 

\if python print(:'varname' == 'Approved' or :'othervar' == 'Special')

which would echo
    print('Approved' == 'Approved' or 'Regular' == 'Special')

to python, which would give the response "True", which is true 

likewise with "bash" (assuming PSQL_EXPR_BASH=bash)

\if bash expr :'varname' = 'Approved'

would echo
    expr 'Approved' = 'Approved'
to bash, which would return 1, which would be true.

So we'd get all that, with only having to internally code for an external launcher, naked booleans, pgbench, defined, and I suppose we should have a negation

\if not <some context> <expression matching that context>

Which I guess would allow

\if not not not <some context> <expression>

For consistency, we might want to change the default context to require an explicit "bool", so

\if bool true

but if we want to do that, we should change it very soon.

tl;dr:
My proposal is:
* do the bare minimum of expression testing in psql (simple scalar truth, variable definition, negation)
* do platform independent client-only-expressions in pgbench mode
* allow inline \gset-ish expressions with sql-mode
* and allow for platform/install dependent expressions via PSQL_EXPR_* env vars.