Re: psql: backslash fix
От | Neil Conway |
---|---|
Тема | Re: psql: backslash fix |
Дата | |
Msg-id | 1015884775.2119.7.camel@jiro обсуждение исходный текст |
Ответ на | Re: psql: backslash fix (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: psql: backslash fix
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: