From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org> |
Cc: | <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: psql: backslash fix |
Date: | 2002-03-11 23:24:17 |
Message-ID: | Pine.LNX.4.30.0203111816460.690-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway writes:
> Well, I won't pretend to understand the psql command parsing code (hand
> parsing w/o flex: yuck!) -- but it seems to me that when it returns the
> "invalid command" error, it should reset the environment: the previous
> command failed, so the user should get an error and a chance to enter a
> new command.
The backslash commands are separate from the SQL commands. The reason is
that the backslash commands may actually operate on the buffer where the
SQL commands are being entered.
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?
1. What you proposed: Execute the command as is and reset the buffer. --
I think not.
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.
3. Ignore the failed backslash command and keep going. This is what it's
doing.
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?
--
Peter Eisentraut peter_e(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2002-03-11 23:41:08 | Re: psql: backslash fix |
Previous Message | Bruce Momjian | 2002-03-11 22:58:12 | Re: support for POSIX 1003.1-2001 hosts |