Noah Misch <n...@leadboat.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers