On Mon, 2002-03-11 at 17:08, Peter Eisentraut wrote:
> Neil Conway writes:
> > nconway=> select foo\\bar;
> > Invalid command \. Try \? for help.
> > nconway-> select 1;
> > ERROR: parser: parse error at or near "select"
>
> This is the correct behavior.
It would be nice if you could have told me that on -hackers ;-)
> > nconway=> select foo\\bar;
> > Invalid command \. Try \? for help.
> > ERROR: Attribute 'foo' not found
> > nconway=> select 1;
> > ?column?
> > ----------
> > 1
>
> The semicolon belongs to the backslash command. Where did this get the
> idea that the query buffer should be executed? You could clear the query
> buffer on a failed backslash command, but I wouldn't like that.
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. With the current code, this isn't the case: they get an
error, but it's very likely that their next command will not be parsed
properly either.
As for the semicolon, AFAICT that's not part of the problem. In current
sources, this still fails:
nconway=> select foo\\bar
Invalid command \. Try \? for help.
nconway-> select 1;
ERROR: parser: parse error at or near "select"
Whether my fix is correct or not, I think that the current behavior is
definately wrong.
Cheers,
Neil
--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC