Re: Patch for psql History Display on MacOSX

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Thu, Sep 04, 2014 at 07:51:03AM -0700, Tom Lane wrote:
>> 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?)

Un-frickin-believable. Comparing the sources for history_get() at

http://www.opensource.apple.com/source/libedit/libedit-28/src/readline.c

vs

http://www.opensource.apple.com/source/libedit/libedit-39/src/readline.c

shows that -39 counts entries from history_base, as expected, but -28
counts them from zero (even though it exports history_base as one).
So that's why the patched loop is misbehaving for you and not for me.

What I'm inclined to do based on this info is to start the loop at
history_base - 1, and ignore NULL returns until we're past history_base.
We could start the loop at zero unconditionally, but in a situation where
libreadline had increased history_base much beyond one, that would be a
bit wasteful.

In any case, it now appears that we'd better test on more than just the
oldest and newest libedits :-(. My confidence in the competence of
libedit's authors has fallen another notch.

regards, tom lane