From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Stepan Rutz <stepan(dot)rutz(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch for psql History Display on MacOSX |
Date: | 2014-09-04 14:51:03 |
Message-ID: | 1201.1409842263@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)com> writes:
> I tried your patches against libedit-28. Wherever a command contains a
> newline, unpatched psql writes the three bytes "\^A" to the history file, and
> patched psql writes the four bytes "\012". Unpatched psql correctly reads
> either form of the history file. Patched psql misinterprets a history file
> created by unpatched psql, placing 0x01 bytes in the recalled command where it
> should have newlines. That's a worrisome compatibility break.
I think you got the test cases backwards, or maybe neglected the aspect
about how unpatched psql will only translate ^J to ^A in the oldest
(or maybe the newest? too pressed for time to recheck right now) history
entry.
The issue is that a patched psql, or a psql with a sufficient old libedit,
will apply ^J -> ^A to all entries when saving, and the reverse when
loading. Without the patch, only the oldest entry gets transformed.
Failure to reverse the encoding in all lines is what creates a
user-visible problem. If we do not fix this, that's what we risk.
We do not escape a problem by refusing to fix it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2014-09-04 14:58:40 | Re: Join push-down support for foreign tables |
Previous Message | Hannu Krosing | 2014-09-04 14:45:06 | Re: PL/pgSQL 1.2 |