From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: fix of some issues with multi-line query editing |
Date: | 2006-03-13 13:42:12 |
Message-ID: | 20060313134212.GC8274@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> I think this patch is seriously broken, and I don't agree with what it's
> trying to accomplish in the first place --- I still haven't found any
> cases where it's an improvement to pull back multiple lines as one
> history entry. For example, if you made a mistake on the fifth line of
> a ten-line CREATE TABLE command, the current code makes it extremely
> inconvenient to fix that: you have to back-arrow or forward-arrow
> tediously over five lines, where before you could pull back one line at
> a time and just edir the line that needed fixing.
Huh, I find precisely that behavior very difficult to use; you end up
pressing up-arrow ten times to get the first line, ten times to get the
second line, ten more times to get the third line, up to a total of a
hundred times! And if you press it nine or eleven times instead of ten
and press "enter" before realizing it (a mistake very easily made), you
are hosed and have to start all over.
Instead of waiting for back-arrow I usually use Alt-b and Alt-f. Or if
I have to go back 20 words, esc-20 alt-b. This is much quicker.
(I agree that there are still bugs. But we should correct those, not
remove the useful behavior.)
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-03-13 13:44:12 | Re: [PATCHES] pg_freespacemap question |
Previous Message | Jonah H. Harris | 2006-03-13 13:41:09 | Re: CREATE SYNONYM ... |