Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) - Mailing list pgsql-hackers
| From | Corey Huinker |
|---|---|
| Subject | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) |
| Date | |
| Msg-id | CADkLM=cWvJPh+-jAuQTPT_117RW49OzVXepioRqOp6ARpQ_KOQ@mail.gmail.com Whole thread Raw |
| In response to | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
(Fabien COELHO <coelho@cri.ensmp.fr>)
|
| List | pgsql-hackers |
On reflection, it seems fairly improbable to me that people would use
\if and friends interactively. They're certainly useful for scripting,
but would you really type commands that you know are going to be ignored?
I'm thinking the one use-case is where a person is debugging a non-interactive script, cuts and pastes it into an interactive script, and then scrolls through command history to fix the bits that didn't work. So, no, you wouldn't *type* them per se, but you'd want the session as if you had. The if-then barking might really be useful in that context.
Therefore, I don't think we should stress out about fitting branching
activity into the prompts. That's just not the use-case. (Note: we
might well have to reconsider that if we get looping, but for now it's
not a problem.) Moreover, if someone is confused because they don't
realize they're inside a failed \if, it's unlikely that a subtle change in
the prompt would help them. So your more in-the-face approach of printing
messages seems good to me.
Glad you like the barking. I'm happy to let the prompt issue rest for now, we can always add it later.
If we DID want it, however, I don't think it'll be hard to add a special prompt (Thinking %T or %Y because they both look like branches, heh), and it could print the if-state stack, maybe something like:
\if true\if true\if false\if true
With a prompt1 of '%T> ' Would then resolve to
ttfi>
for true, true, false, ignored.
This is just idle musing, I'm perfectly happy to leave it out entirely.
This seems more or less reasonable, although:
> # \endif
> active \endif, executing commands
looks a bit weird. Maybe instead say "exited \if, executing commands"?
+1
BTW, what is your policy about nesting these things in include files?
My immediate inclination is that if we hit EOF with open \if state,
we should drop it and revert to the state in the surrounding file.
Otherwise things will be way too confusing.
That's how it works now if you have ON_ERROR_STOP off, plus an error message telling you about the imbalance. If you have ON_ERROR_STOP on, it's fatal.
All \if-\endif pairs must be balanced within a file (well, within a MainLoop, but to the user it looks like a file). Every new file opened via \i or \ir starts a new if-stack. Because commands in an inactive branch are never executed, we don't have to worry about the state of the parent stack when we do a \i, because we know it's trues all the way down.
We chose this not so much because if-endif needed it (we could have thrown it into the pset struct just as easily), but because of the issues that might come up with a \while loop: needing to remember previous GOTO points in a file (if the input even *is* a file...) is going to be hard enough, remembering them across files would be harder, and further complicated by the possibility that a file \included on one iteration might not be included on the next (or vice versa)...and like you said, way too confusing.
We chose this not so much because if-endif needed it (we could have thrown it into the pset struct just as easily), but because of the issues that might come up with a \while loop: needing to remember previous GOTO points in a file (if the input even *is* a file...) is going to be hard enough, remembering them across files would be harder, and further complicated by the possibility that a file \included on one iteration might not be included on the next (or vice versa)...and like you said, way too confusing.
pgsql-hackers by date: