Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

>
> I'm not sure that '@' is the best choice, but this is just one char.

> I noticed that it takes precedence over '!'. Why not. ISTM that orthogonal
> features are not shown independently, but this is a preexisting state, and
> it allows to have a shorter prompt, so why not.
>

My reasoning was this: if you're in a false block, and you're not connected
to a db, the \c isn't going to work for you until you get out of the false
block, so right now being in a false block is a bigger problem than not
being connected to a db. I have no strong opinion about what should happen
here, so I welcome suggestions for what tops what.

>
> Anyway, the '%R' documentation needs to be updated.

Done.

> It could be nice to keep test cases that show what may happen?
>

Restored. It looks weird now, but it fixes the unterminated quoted string.

> The various simplifications required result in the feature being more
> error prone for the user. Maybe the documentation could add some kind of
> warning about that?

I changed the paragraph to
Lines within false branches are parsed normally, however, any
completed
queries are not sent to the server, and any completed commands other
than conditionals (<command>\if</command>, <command>\elif</command>,
<command>\else</command>, <command>\endif</command>) are ignored.

There's no mention that psql variables AREN'T expanded, so the user has
every expectation that they are.

>
> Add space after comma when calling send_query.
>

Done.

>
> I'm not sure why you removed the comments before \if in the doc example.
> Maybe keep a one liner?
>

Didn't mean to, restored.

> Why not reuse the pop loop trick to "destroy" the stack?

Forgot about that, restored.