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.1611291254040.19314@lancre
Whole thread Raw
In response to Re: PSQL commands: \quit_if, \quit_unless  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: PSQL commands: \quit_if, \quit_unless
Re: PSQL commands: \quit_if, \quit_unless
List pgsql-hackers
Hello Pavel,

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

Indeed, an error on a conditional construct should stop the script, which 
is slightly different that "go on whatever", which is okay in the 
interactive mode.

I do not see that as an issue, just as features which are more interactive 
vs script oriented and behave accordingly: typing a \if in interactive 
does not makes much sense, because you have tested something is there, so 
you know the answer and can act directly, so there is no point using a 
condition.

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

My 0,02 €, which is just a personal opinion:

I think that handling manually "!/not" would be worth the effort rather 
than having two commands, especially if the boolean expression syntax may 
be extended some day and the negative if would become obsolete.

If there is a negative condition syntax, I would slightly prefer \ifnot to 
\if_not or worse \unless. I would disaprove strongly of \unless because it 
looses the clear symmetry with a closing \fi.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Amos Bird
Date:
Subject: Re: make default TABLESPACE belong to target table.
Next
From: Fabien COELHO
Date:
Subject: tiny psql doc inconsistency