Re: PSQL commands: \quit_if, \quit_unless - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: PSQL commands: \quit_if, \quit_unless
Date
Msg-id alpine.DEB.2.20.1611290826470.19314@lancre
Whole thread Raw
In response to Re: PSQL commands: \quit_if, \quit_unless  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PSQL commands: \quit_if, \quit_unless
List 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
avoidingan 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



pgsql-hackers by date:

Previous
From: Vladimir Borodin
Date:
Subject: Re: GIN non-intrusive vacuum of posting tree
Next
From: Craig Ringer
Date:
Subject: Re: [PATCH] Logical decoding timeline following take II