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: