Re: psql: backslash fix

Neil,
You don't actually _use_ psql much, do you? Yes, it's a different mode of
operation than a straight interpreter. That's actually a good thing. The
change you've suggested 'for consistencies sake' strike me as making
psql a lot more difficult to use, in particular, clearing the buffer
on error. One of the big differences is that multiline input is handled
differently - if you've got a long buffer, it's in multiple lines. Perhaps
that should be changed to more like bash's handling of multiline input,
bug throwing it away is wrong.

Your comparison with vi is wrong: put vi in linemode (i.e. use ex)
and then thow an error: does it clear your edit buffer? I don't think so.

One change I _would_ like to see is after invoking the external editor,
dump the editted command into the history, as well as sending it to the
backend. This would probably need the multiline capability mentioned
above, however.

On Mon, Mar 11, 2002 at 06:41:08PM -0500, Neil Conway wrote:
> On Mon, 2002-03-11 at 18:24, Peter Eisentraut wrote:
> > The backslash commands are separate from the SQL commands.
>
> This distinction isn't very obvious to the user. Sure, the backslash
> commands look very different from SQL -- but you're still entering input
> into psql. A lot of backslash commands (e.g. \d ) are just short-cuts
> for the equivalent SQL. I'd say that having two different methods of
> handling errors is needless and confusing.
>
> This is part of the confusion in this case: a malformed SQL command
> resets the buffer, a malformed backslash command does not. I'd vote to
> make these consistent, or at least make the differing behavior a lot
> more obvious to the user.
>
> > For instance, say I start entering a command and then decide not to do it
> > and reset the buffer.
> >
> > delete from table1
> > \R
> >
> > Instead of \r I entered \R, as a typo. There is no \R command, so what do
> > you do?
>
> Give the user an error. If they want to retry the command, let them use
> the up-arrow, or even copy-and-paste. I think psql is being too fancy in
> this case and trying to read the user's mind: if they typed in malformed
> input, let them know "your input was malformed" and let them start over
> again.
>
> > 2. Clear the buffer. This might be reasonable, but I find it totally
> > unnecessary. Maybe I wanted to type \p or \e because my buffer is
> > already 23 lines long.
>
> As I said, they can get back their previous buffer using the up-arrow.
>
> > 3. Ignore the failed backslash command and keep going. This is what it's
> > doing.
>
> Even if we want to continue with this behavior, I think the current
> implementation is confusing: psql should recall the previous buffer, set
> the prompt to "=>", and allow the user to continue editing the command.
> For example:
>
> nconway=> select foo\\bar;
> Invalid command \. Try \? for help.
> nconway=> select foo
> ^^^^^^^^^^ recalled by psql, the user can continue
> typing after this point
>
> But as I said before, I'd prefer that we make the behavior consistent
> with the backend.
>
> > Think of psql as an editor and (some of) the backslash commands as editor
> > commands. When you enter a wrong command in your editor, what does it do?
>
> It gives me an error. For instance, in vim:
>
> ":set nooooexpandtab" -> "Unknown option: nooooexpandtab"
>
> And it returns me to my previous mode. It does _not_ recall ":set ..."
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilconway(at)rogers(dot)com>
> PGP Key ID: DB3C29FC
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster