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 08:07:36
Message-ID: alpine.DEB.2.20.1703010851190.762@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2017-03-01 08:46:59 Re: WIP: Covering + unique indexes.
Previous Message Tsunakawa, Takayuki 2017-03-01 08:00:49 Re: Statement-level rollback