Re: PSQL commands: \quit_if, \quit_unless

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PSQL commands: \quit_if, \quit_unless
Date: 2016-11-30 08:47:20
Message-ID: alpine.DEB.2.20.1611300938300.13369@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2016-11-30 08:53:46 Re: postgres_fdw : altering foreign table not invalidating prepare statement execution plan.
Previous Message Etsuro Fujita 2016-11-30 08:29:47 Re: Push down more UPDATEs/DELETEs in postgres_fdw