Re: psql: backslash fix
От | Neil Conway |
---|---|
Тема | Re: psql: backslash fix |
Дата | |
Msg-id | 1015959200.4927.35.camel@jiro обсуждение исходный текст |
Ответ на | Re: psql: backslash fix ("Ross J. Reedstrom" <reedstrm@rice.edu>) |
Ответы |
Re: psql: backslash fix
|
Список | pgsql-patches |
On Tue, 2002-03-12 at 13:21, Ross J. Reedstrom wrote: > Neil, > You don't actually _use_ psql much, do you? I do use it a fair amount -- but I find the accusatory tone a bit unnecessary. I'm trying to improve psql here -- perhaps our views differ, but so what? I'm willing to be convinced... > Yes, it's a different mode of > operation than a straight interpreter. That's actually a good thing. The > change you've suggested 'for consistencies sake' strike me as making > psql a lot more difficult to use, in particular, clearing the buffer > on error. One of the big differences is that multiline input is handled > differently - if you've got a long buffer, it's in multiple lines. Perhaps > that should be changed to more like bash's handling of multiline input, > bug throwing it away is wrong. Well sure, don't clear the buffer on error -- recall the last line of input and put the cursor where the error occured. That's another one of the suggestions I made, and I think it satisfies your concerns. Peter said he'd look into implementing it. Regardless, I do think the current behavior should be improved. In the case I ran into (a simple SQL statement with a malformed backslash command) psql behaves in an extremely unintuitive fashion: the previous buffer is silently prepended to the current one, and the only indication of this is that the prompt changes to a "->". Whether this is improved by clearing the buffer (and thus returning to "=>"), or by recalling the previous buffer and printing it to the screen (allowing the user to continue editing it), I don't really mind. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
В списке pgsql-patches по дате отправления: