Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Erik Rijkers <er(at)xs4all(dot)nl>, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Date: 2017-03-01 16:34:00
Message-ID: CADkLM=fCuLWGxEqmWrOk2tZWEi0bAU6xO58+O5-VxLWpnFFhoA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 1, 2017 at 3:07 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

>
> Hello Corey,
>
> It doesn't strike me as much cleaner, but it's no worse, either.
>>
>
> Hmmm.
>
> The "if (x) { x = ... ; if (x) {" does not help much to improve
> readability and understandability...
>
> My 0.02€ about v19:
>
> If there are two errors, I do not care which one is shown, both will have
> to be fixed anyway in the end... So I would suggest to choose the simplest
> possible implementation:
>
> on elif:
> always eval expression
> => possible eval error
> switch
> => including detecting misplaced elif errors
>
> If the second error must absolutely be shown in all cases, then add a
> second misplaced elif detection in the eval expression failure branch:
>
> on elif
> always eval
> if (eval failed)
> also checked for misplaced (hey user, you have 2 errors in fact...)
> bye bye...
> // else eval was fine
> switch
> including misplaced elif detection
>
> If the committer is angry at these simple approach, then revert to the
> strange looking and hard to understand switch-if-switch solution (~ v18, or
> some simplified? v19), but I do not think the be weak benefit is worth the
> code complexity.
>
> --
> Fabien.

Just to make things easy for the committer, the existing code only shows
the user one error:

on elif
if misplaced elif
misplaced elif error
else
eval expression
=> possible eval error
set new status if eval fine

The issue at hand being the benefit to the user vs code complexity.

So, shall we send this off to the committers and let them decide?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Soref 2017-03-01 16:35:12 Re: Possible spelling fixes
Previous Message Andres Freund 2017-03-01 16:27:34 Re: Time to drop old-style (V0) functions?