Hello Robert,
[...] 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.
Ok. I think that we agree that the stack was too much details.
How about just introducing a new value for %R?
Yes. That is indeed one of the idea being discussed.
[...] , or @ if commands are currently being ignored because of the
result of an \if test.
Currently I find that %R logic is quite good, with "=" for give me
something, "^" is start line regular expression for one line, "!" for
beware someting is amiss, and in prompt2 "-" for continuation, '"' for in
double quotes, "(" for in parenthesis and so on.
What would be the mnemonic for "," an "@"?
By shortening one of the suggestion down to two characters, we may have
three cases:
"?t" for "in condition, in true block"
"?f" for "in condition, in false block (but true yet to come)"
"?z" for "in condition, waiting for the end (true has been executed)".
So no indication about the stack depth and contents. tfz for true false
and sleeping seem quite easy to infer and understand. "?" is also needed
as a separator with the previous field which is the database name
sometimes:
calvin=> \if false
calvin?f=> \echo 1
calvin?f=> \elif true
calvin?t=> \echo 2
2
calvin?t=> \else
calvin?z=> \echo 3
calvin?z=> \endif
calvin=>
With the suggested , and @:
calvin=> \if false
calvin,=> \echo 1
calvin,=> \elif true
calvin@=> \echo 2
2
calvin@=> \else
calvin,=> \echo 3
calvin,=> \endif
calvin=>
If I can find some simple mnemonic for "," vs "@" for being executed vs
ignored, I could live with that, but nothing obvious comes to my mind.
The "?" for condition and Corey's [tfz] looked quite intuitive/mnemonic to
me. The drawback is that it is 2 chars vs one char in above.
[...] I think that's all you need here: a way to alert users as to
whether commands are being ignored, or not.
Yep.
[...]
To sum up your points: just update %R (ok), keep it simple/short (ok...
but how simple [2 vs 3 states] and short [1 or 2 chars]), and no real need
to be too nice with the user beyond the vital (ok, that significantly
simplifies things).
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
