Noah Misch <noah@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