I think it's really time we seriously considered adding some flow control logic, though.
Yeah, maybe. I'd be interested to see a fully worked out proposal for that.
I agree that designing a fuller proposal before including individual parts would be great and result in a more consistent result.
In order to bootstrap the discussion, I suggest the following:
- boolexpr is a simple "boolean" (t, non 0 int, non empty string.. as proposed by Corey and Pavel) or !/not boolexp ; it could be extended if necessary, but I would try to avoid that, as
Now, the psql statements are designed do nothing in syntax error. I am not sure about be more strict in this case. I see strong advantages - but it can be little bit different than current behave.
- actual more complex expressions could be left to the server through SQL which simplifies the client a lot by avoiding an expression language altogether
- then having a conditional block is very versatile and can be adapted to many use cases... maybe all
- \quit CODE, or I would prefer \exit CODE, could be used to exit while controlling the status
It could look like (although I do not like gset in this context, but anyway):
SELECT ... AS has_foo_extension \gset SELECT ... AS has_bla_extension \gset \if :has_foo_extension ... \elif :has_bla_extension ... \else -- no foo nor bla extension \echo please install foo or bla extension \exit 1 \fi -- extension ... SELECT ... AS has_xxx_feature \gset \if ! :has_xxx_feature
I prefer the commands instead symbols - the parsing and processing symbols should be more complex than it is now. A psql parser is very simple - and any complex syntax enforces lot of code.
\if_not
Regards
Pavel
\echo "feature xxx is needed, aborting" \exit 2 \fi ...