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
  calvin?t=> \else
  calvin?z=> \echo 3
  calvin?z=> \endif

With the suggested , and @:

  calvin=> \if false
  calvin,=> \echo 1
  calvin,=> \elif true
  calvin@=> \echo 2
  calvin@=> \else
  calvin,=> \echo 3
  calvin,=> \endif

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.



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).


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to