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.1703171706560.21944@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hello Tom, >>> I also fear that there are corner cases where the behavior would still >>> be inconsistent. Consider >>> >>> \if ... >>> \set foo `echo \endif should not appear here` > >> In this instance, ISTM that there is no problem. On "\if true", set is >> executed, all is well. On "\if false", the whole line would be skipped >> because the if-related commands are only expected on their own line, all >> is well again. No problem. > > AFAICS, you misunderstood the example completely, or else you're proposing > syntax restrictions that are even more bizarre and unintelligible than > I thought before. Hmmm. The example you put forward does work as expected with the rule I suggested. It does not prove that the rules are good or sane, I'm just stating that the example would work consistently. > We cannot have a situation where the syntax rules for backslash commands > inside an \if are fundamentally different from what they are elsewhere; Indeed, I do not see an issue with requiring some new backslash commands to be on their own line: Any average programmer would put them like that anyway for readability. What is the point of trying to write code to handle strange unmaintainable oneliners? > that's just going to lead to confusion and bug reports. Whatever is done, there will be some confusion and bug reports:-) If someone writes a strange one-liner and see that it generates errors, then the error messages should be clear enough. Maybe they will complain and fill in bugs because they like backslash-command oneliners. That is life. Now you are the committer and Corey is the developer. I'm just a reviewer trying to help. I can still review a larger patch which tries to be subtly compatible with a lack of previous clear design by adding code complexity, even if I think that this particular effort is a bad idea (i.e. mis-spent resource on a useless sub-feature which makes future maintenance harder). With some luck, Corey may find a way of doing it which is not too bad. -- Fabien.
В списке pgsql-hackers по дате отправления: