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.1611300938300.13369@lancre
Whole thread Raw
In response to Re: PSQL commands: \quit_if, \quit_unless  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: PSQL commands: \quit_if, \quit_unless
List pgsql-hackers
Hello Andrew,

>> I cannot remember a language with elseif* variants, and I find them quite 
>> ugly, so from an aethetical point of view I would prefer to avoid that... 
>> On the other hand having an "else if" capability makes sense (eg do 
>> something slightly different for various versions of pg), so that would 
>> suggest to stick to a simpler "if" without variants, if possible.
>
> FTR I *strongly* disagree with this. (And if you can't remember a language 
> that comes with them then you need to get out more. The Bourne shell, where 
> it's spelled "elif", and Ada are two obvious examples.)

There may be a misunderstanding somewhere.

I'm rather in favor of having "elif/elsif/elseif/..." constructs, 
especially if they can be useful in realistic examples, which is not clear 
yet for psql scripts.

I'm arguing against "if/elif" *variants* in the sense of various 
conditional semantics: e.g. in cpp you have several "if"s (ifdef ifndef 
if), but you do not have all the corresponding "elif"s (elifdef 
elifndef...), there is only one "elif". In cpp "ifdef"/"ifndef" were 
obsoleted by "if" with minimal expression support (#if 
!defined(HAS_SOMETHING) ...) and only this "if" has its "elif".

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Push down more UPDATEs/DELETEs in postgres_fdw
Next
From: Amit Langote
Date:
Subject: Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.