From: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: psql: backslash fix |
Date: | 2002-03-11 23:41:08 |
Message-ID: | 1015890068.2119.32.camel@jiro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)rogers(dot)com>
PGP Key ID: DB3C29FC
From | Date | Subject | |
---|---|---|---|
Next Message | Dominic J. Eidson | 2002-03-11 23:59:32 | Re: support for POSIX 1003.1-2001 hosts |
Previous Message | Peter Eisentraut | 2002-03-11 23:24:17 | Re: psql: backslash fix |