Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) |
Date | |
Msg-id | CA+TgmoYOZFrWqZ9LenvGfz13nd1onm_zxNfjHECZt+a_qy6+sg@mail.gmail.com Whole thread Raw |
In response to | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Responses |
Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) |
List | pgsql-hackers |
On Sat, Feb 11, 2017 at 2:43 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote: >> Ok, so that's not just PROMPT_READY, that's every prompt...which might be >> ok. ? is a great optional cue, and you're thinking on 2 levels deep, 2nd >> level always being '.'? > > Yep. The idea is to keep it short, but to still have something to say "there > are more levels" in the stack, hence the one dot. Basically I just > compressed your 4 level proposal, and added a separator to deal with the > preceding stuff and suggest the conditional. I think we should try to make this REALLY simple. We don't really want to have everybody have to change their PROMPT1 and PROMPT2 strings for this one feature. How about just introducing a new value for %R? The documentation currently says: In prompt 1 normally =, but ^ if in single-line mode, or ! if the session is disconnected from the database (which can happen if \connect fails). ...and suppose we just extend that to add: , or @ if commands are currently being ignored because of the result of an \if test. The latter would include being in the \if section when the conditional was true as well as being in the \else section when the conditional was false. I think that's all you need here: a way to alert users as to whether commands are being ignored, or not. Putting details in about precisely why they are being ignored seems like it's too complicated; people won't remember how to decode some bizarre series of glyphs that we output. Telling them whether their next command is set to be ignored or executed is good enough; if the answer isn't what they expect, they can debug their script to figure out what they screwed up. Also, keep in mind that people don't need to know everything from the current prompt. They can try to debug things by looking back at previous prompts. They'll understand that \if is going to introduce a new nesting level and \endif is going to end one, and that \else and \elseif may change things. Aside from keeping the code simple so we can maintain it and the output simple so that users can remember what it means, I just don't believe that it's really going to be helpful to convey much detail here. People aren't going to paste in a gigaton of commands and then look only at the last line of the output and try to understand what it's telling them, or if they do that and are confused, I think nobody will really feel bad about giving them the advice "scroll up" or "try a simpler test case first". Further keep in mind that eventually somebody's going to code \while or \for or something, and then there are going to be even more possible states here. Just when you've figured out what tfzffft means, they'll be the case of a \while loop which is getting skipped because the condition at the top turned out to be false on the first iteration, or where (half-joking) we're skipping commands until we find the label that matches an executed \goto. Writing maintainable code includes leaving room open for other people to do stuff we can't even foresee today, and that means we need not to use up a disproportionate number of the glyphs that can reasonably be used in a psql prompt just on this. This is one small feature out of many that psql has, and one small hint to the user about whether it's currently causing commands to be skipped seems sufficient. All IMHO, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: