Re: Undefined psql variables

2017-04-13 19:46 GMT+02:00 Corey Huinker <corey(dot)huinker(at)gmail(dot)com>:

>
>> > 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>
>
>
it looks like overengineering - I don't think so string comparation should
be supported in two three languages.

Can live with it, but more prefer simple pgbench only language there

The one line commands is limited due readability

we can introduce "language blocks" where can be possible set some values.
This looks really scary.

bash is supported already

probably you can write today

\if `basexpr`

>
> 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.
>