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. 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