On Tue, Sep 02, 2014 at 01:56:34AM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Mon, Sep 01, 2014 at 10:22:57PM -0400, Tom Lane wrote: > >> Also, as best I can tell, .psql_history files from older libedit versions > >> are not forward-compatible to current libedit versions because of the > >> failure of the decode_history() loop to reach all lines of the file > >> when using current libedit. That is also a back-patchable bug fix IMO. > >> (Closer investigation suggests this is a bug or definitional change in > >> libedit's history_set_pos, not so much in next_history vs > >> previous_history. But whatever it is, it behooves us to work around it.) > > > I haven't studied this part of the topic other than to read what you have > > written. All other things being equal, I agree. If fixing this will make > > psql-9.3.6 w/ libedit-20141001 write history files that confuse psql-9.3.5 > > w/ > > libedit-20141001, that changes the calculus. Will it? > > I'm not sure exactly when things changed, but I have verified that the > existing loops in decode/encode_history visit all lines of the history > when using OS X Tiger's libedit library. On OS X Mavericks, the loops > visit only the oldest history entry, as Stepan reported. This means that > there may be libedit-style ~/.psql_history files out there in which ^A has > been substituted for ^J (in lines after the oldest), which will not be > correctly reloaded by psql versions using newer libedit. > > It's certainly arguable whether this is an issue warranting a back-patch, > since we've not heard field complaints about it AFAIR. But I think we > ought to do so. I think "psql N produces files that psql N+1 can't read" > is worse than the reverse case, and that's exactly what we're debating > here.
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers