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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
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 17:23:00
Message-ID: alpine.DEB.2.20.1703011742300.762@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

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

Hmmm.

One of my point is that I do not really see the user benefit... for me the
issue is to have no user benefit and code complexity.

The case we are discussing is for the user who decides to write code with
*two* errors on the same line:

\if good-condition
\else
\elif bad-condition
\endif

with an added complexity to show the elif bad position error first. Why
should we care so much for such a special case?

Maybe an alternative could be to write simpler code anyway, somehow like
it was before:

// on "elif"
switch (peek(state)) {
case NONE: error;
case ELSE_TRUE: error;
case ELSE_FALSE: error;
case IGNORED: break;
case TRUE: poke IGNORED;
case FALSE:
success = evaluate(&is_true)
if (!success)
error;
else if (is_true)
poke TRUE
default: error;
}

The only difference is that the evaluation is not done when it is not
needed (what a draw back) but ISTM that it is significantly easier to
understand and maintain.

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

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-03-01 17:24:19 Re: objsubid vs subobjid
Previous Message Peter Eisentraut 2017-03-01 17:18:07 Re: Restricting maximum keep segments by repslots