I wrote:
> Stepan Rutz <stepan.r...@gmx.de> writes:
>> Anyway, I am sure the iteration used in encode_history and decode_history in
>> input.c does not work on libedit.
> Yeah, I noticed your comment about that. That seems odd; a look at the
> Apple libedit sources suggests it should work. I was just about to trace
> through the logic and try to see what's happening.
Sigh ... the answer is that libedit has the direction of traversal
backwards compared to libreadline. If you replace next_history() by
previous_history() in those loops, then it works as expected.
> The reason nobody noticed is possibly that libedit doesn't actually need
> the newline-encoding hack.
Indeed, that's the reason.
> However, we should probably fix the loops if
> they aren't working as expected on libedit, just in case somebody tries
> to copy the logic for some other purpose.
We should either do that, or document what's actually going on here.
A disadvantage of fixing this is that psql versions containing the fix
would be incompatible with versions without (since writing out a history
file containing ^A in place of ^J, and not reversing that encoding upon
reload, would lead to messed-up history data). However, I have a feeling
that we'd better proceed with a fix. Sooner or later, somebody is going
to point out to the libedit guys that they've emulated libreadline
incorrectly. If they fix that, we'll have a situation where psql's using
different libedit versions are incompatible, which would be even more of
a mess.
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
