>
>
> 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.
>
True
> The closest case is CPP with its line-oriented #-prefix syntax, and I
> still think that we
1: unrecognized value "whatever" for "\if"; assuming "on"
I do not think that the script should continue with such an assumption.
I agree, and this means we can't use ParseVariableBool() as-is. I
already broke out argument reading to it's own function, knowing that
it'd be the stub for
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
On Mon, Jan 23, 2017 at 4:12 PM, Corey Huinker
wrote:
> I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL
>> has "ELSIF" like perl, that I do not like much, though. Given the syntax
>> and behavioral proximity with cpp, I suggest that "elif" would
>
> I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL
> has "ELSIF" like perl, that I do not like much, though. Given the syntax
> and behavioral proximity with cpp, I suggest that "elif" would be a better
> choice.
>
I'm personally indifferent to elif vs elsif vs elseif,
A few comments:
Argh, better with the attachements:-(
--
Fabien.
if-error-1.sql
Description: application/sql
if-error-2.sql
Description: application/sql
if-error-3.sql
Description: application/sql
if-error-4.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list
And here's the patch. I've changed the subject line and will be submitting
a new entry to the commitfest.
A few comments:
Patch applies, make check is ok, but currently really too partial.
I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL
has "ELSIF" like perl, that
101 - 107 of 107 matches
Mail list logo