Hello Corey,

Tom was pretty adamant that invalid commands are not executed. So in a case
like this, with ON_ERROR_STOP off:

\if false
\echo 'a'
\elif true
\echo 'b'
\elif invalid
\echo 'c'

Both 'b' and 'c' should print, because "\elif invalid" should not execute.
The code I had before was simpler, but it missed that.

Hmmm. You can still have it with one switch, by repeating the evaluation under true and ignore, even if the value is not used:

    case NONE: error;
    case ELSE_TRUE: error;
    case ELSE_FALSE: error;
    case IF_TRUE:
        if (eval())
        else error;
    case IF_FALSE:
        if (eval())
        else error;
    case IGNORE:
        if (eval())
        else error;

Ok, so here's one idea I tossed around, maybe this will strike the right
balance for you.  If I create a function like this: [...]

Does that handle your objections?

For me, it is only slightly better: I think that for helping understanding and maintenance, the automaton state transitions should be all clear and loud in just one place, so I would really like to see a single common structure:

  if (is "if") switch on all states;
  else if (is "elif") switch on all states;
  else if (is "else") switch on all states;
  else if (is "endif") switch on all states;

And minimal necessary error handling around that.

Your suggestion does not achieve this, although I agree that the code structure would be cleaner thanks to the function.

p.s.  do we try to avoid constructs like    if (success = my_function(var1,
var2))   ?

I think it is allowed because I found some of them with grep (libpq, ecpg, postmaster, pg_dump, pg_upgrade...). They require added parentheses around the assignment:

  if ((success = eval())) ...


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to