Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
| От | Fabien COELHO |
|---|---|
| Тема | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) |
| Дата | |
| Msg-id | alpine.DEB.2.20.1703010851190.762@lancre обсуждение исходный текст |
| Ответ на | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless) (Corey Huinker <corey.huinker@gmail.com>) |
| Ответы |
Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands:\quit_if, \quit_unless)
|
| Список | 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.
В списке pgsql-hackers по дате отправления: