On Thu, Sep 04, 2014 at 07:51:03AM -0700, Tom Lane wrote:
> Noah Misch <[email protected]> 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.
I, too, had more-productive uses for this time, but morbid curiosity
prevailed. It was the latter: I was testing a one-command history file.
Under libedit-28, unpatched psql writes "^A" for newlines in the oldest
command and "\012" for newlines in subsequent commands. Patched psql writes
"\012" for newlines in the oldest command and "^A" for newlines in subsequent
commands. (Surely a comment is in order if that's intentional. Wasn't the
point to discontinue making the oldest command a special case?) Here's the
matrix of behaviors when recalling history under libedit-28:
master using master-written history:
oldest command: ok
rest: ok
patched using master-written history:
oldest command: broken if it contained a newline
rest: ok
master using patched-written history
oldest command: ok
rest: each broken if it contained a newline
patched using patched-written history
oldest command: ok
rest: ok
Corrupting just the oldest history entry, only when it happens to contain a
newline, is acceptable. If one assumes that users who deploy multiple major
releases use a consistent vintage of minor release, the compatibility problems
after back-patching this change are negligible. That assumption has moderate
credibility.
> We do not escape a problem by refusing to fix it.
I have not recommended a general refusal of fixes for this bug.
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
