Not so happy with psql's new multiline behavior
От | Tom Lane |
---|---|
Тема | Not so happy with psql's new multiline behavior |
Дата | |
Msg-id | 21637.1141492105@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Not so happy with psql's new multiline behavior
Re: Not so happy with psql's new multiline behavior Re: Not so happy with psql's new multiline behavior Re: Not so happy with psql's new multiline behavior |
Список | pgsql-hackers |
Has anyone else been finding the recent behavior of CVS-tip psql to be a disimprovement? I've gotten sufficiently annoyed with it that I'm ready to propose reverting this patch: 2006-02-11 16:55 momjian * src/bin/psql/: help.c, input.c, input.h, mainloop.c, prompt.c,tab-complete.c: o Improve psql's handling of multi-line statements Currently, while \e saves a single statement as one entry,interactive statements are saved one line at atime. Ideally allstatements would be saved like \e does.Sergey E. Koposov Maybe it's just that I'm too used to the old behavior, but I don't like anything about the way it works now. As an example, the new behavior is extremely unfriendly to backslash commands. I just got done typing a long command and then deciding that I would like to have \timing on, so I hit return (which in prior versions would have entered the line into the history buffer), typed \timing, hit return again, hit control-P, and found that I'd lost my long command. In other situations I find that control-P pulls back weird combinations of SQL and backslash commands, and there's no way AFAICT to separate the two. At a minimum this code has to be fixed to understand the difference between backslash commands and SQL lines, and not combine them in history entries; otherwise we should revert it. I'm leaning to "revert" since I haven't actually seen a case where pulling back multiple lines helped me ... but maybe that just reflects that I don't retype multiline SQL commands all that much. Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: