From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) |
Date: | 2017-01-24 06:06:58 |
Message-ID: | alpine.DEB.2.20.1701240644360.31421@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
>> I'm personally indifferent to elif vs elsif vs elseif, but I think elseif
>> was the consensus. It's easy enough to change.
>
> Went with elsif to follow pl/pgsql. In reviewing the original thread it
> seemed that "elif" was linked to "fi" and that got some negative feedback.
As I understood it, the negative feeback was really about sh inspiration
"if/fi", not about elif/elsif/elseif. I do not think that there was an
expressed consensus about the later.
Else-if variants from different languages include:
VB: If ElseIf Else End If (with optional Then)
PHP: if {} elseif {} else {}
Tcl: if {} elseif {} else {}
PL/pgSQL: IF ... THEN ... ELSIF ... ELSE ... END IF;
Perl: if {} elsif {} else {}
Ruby: if elsif else end
CPP: #if #elif #else #endif
Python: if : elif: else:
bash: if [] then ... elif ... else ... fi
The closest case is CPP with its line-oriented #-prefix syntax, and I
still think that we should do it like that.
> I went looking for other examples of explicit /* PASSTHROUGH */ comments
> and could find none. Could you explain what it is you want me to fix with
> the switch statements?
Sorry, I got it wrong. The comment (which is FALLTHROUGH or FALL THROUGH,
not PASSTHROUGH) is required if there is specific code in a case and the
case is expected to continue with executing the next case code as well.
This is quite rare, and it is not the case for your code, which just has
some comments in one case.
--
Fabien
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2017-01-24 06:11:52 | Re: pageinspect: Hash index support |
Previous Message | Pavel Stehule | 2017-01-24 05:43:41 | Re: PoC plpgsql - possibility to force custom or generic plan |