Re: psql: backslash fix - Mailing list pgsql-patches

From Neil Conway
Subject Re: psql: backslash fix
Date
Msg-id 1015890068.2119.32.camel@jiro
Whole thread Raw
In response to Re: psql: backslash fix  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: psql: backslash fix  (Peter Eisentraut <peter_e@gmx.net>)
Re: psql: backslash fix  ("Ross J. Reedstrom" <reedstrm@rice.edu>)
List pgsql-patches
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@rogers.com>
PGP Key ID: DB3C29FC


pgsql-patches by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: psql: backslash fix
Next
From: "Dominic J. Eidson"
Date:
Subject: Re: support for POSIX 1003.1-2001 hosts