From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PSQL commands: \quit_if, \quit_unless |
Date: | 2016-11-29 07:44:07 |
Message-ID: | alpine.DEB.2.20.1611290826470.19314@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
>> 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
- 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
\echo "feature xxx is needed, aborting"
\exit 2
\fi
...
--
Fabien
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2016-11-29 07:55:23 | Re: [PATCH] Logical decoding timeline following take II |
Previous Message | Vladimir Borodin | 2016-11-29 07:03:55 | Re: GIN non-intrusive vacuum of posting tree |