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 по дате отправления: