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=eeyM_5eFyty6S_VDK-rJXNaKPJmB5mELC04n1xfWZK=Q@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 12:23 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Corey,

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

Currently it is really:

  switch (state) {
  case NONE:
  case ELSE_TRUE:
  case ELSE_FALSE:
     success = false;
     show some error
  default:
  }
  if (success) {
    success = evaluate_expression(...);
    if (success) {
       switch (state) {
       case ...:
       default:
       }
    }
  }

Which I do not find so neat. The previous one with nested switch-if-switch looked as bad.

That is accurate. The only positive it has is that the user only experiences one error, and it's the first error that was encountered if reading top-to-bottom, left to right. It is an issue of which we prioritize - user experience or simpler code.

Now if you want to require committer opinion on this one, fine with me.

Rather than speculate on what a committer thinks of this edge case (and making a patch for each possible theory), I'd rather just ask them what their priorities are and which user experience they favor.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Patch: Optimize memory allocation in function'bringetbitmap'
Next
From: "Tels"
Date:
Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan[take-2]