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.1703170710320.4278@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 & Tom, > What is not done: > - skipped slash commands still consume the rest of the line > > That last part is big, to quote Tom: > > * More generally, I do not think that the approach of having exec_command > simply fall out immediately when in a false branch is going to work, > because it ignores the fact that different backslash commands have > different argument parsing rules. Some will eat the rest of the line and > some won't. I'm afraid that it might be necessary to remove that code > block and add a test to every single backslash command that decides > whether to actually perform its action after it's consumed its arguments. > That would be tedious :-(. But as it stands, backslash commands will get > parsed differently (ie with potentially-different ending points) depending > on whether they're in a live branch or not, and that seems just way too > error-prone to be allowed to stand. ISTM that I've tried to suggest to work around that complexity by: - document that \if-related commands should only occurat line start (and extend to eol). - detect and complain when this is not the case. - if some border cases are notdetected, call it a feature. ISTM that Tom did not respond to this possibly simpler approach... Maybe a "no" would be enough before starting heavy work which would touch all other commands... Tom? -- Fabien.
В списке pgsql-hackers по дате отправления: