Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
Date
Msg-id CADkLM=fCuLWGxEqmWrOk2tZWEi0bAU6xO58+O5-VxLWpnFFhoA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


On Wed, Mar 1, 2017 at 3:07 AM, Fabien COELHO <coelho@cri.ensmp.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?

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Time to drop old-style (V0) functions?
Next
From: Josh Soref
Date:
Subject: Re: [HACKERS] Possible spelling fixes