Skip site navigation (1) Skip section navigation (2)

Re: psql: backslash fix

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 (view raw, whole thread or download thread mbox)
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

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



Neil Conway <neilconway(at)rogers(dot)com>

In response to


pgsql-patches by date

Next:From: Dominic J. EidsonDate: 2002-03-11 23:59:32
Subject: Re: support for POSIX 1003.1-2001 hosts
Previous:From: Peter EisentrautDate: 2002-03-11 23:24:17
Subject: Re: psql: backslash fix

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group