Noah Misch <noah@leadboat.com> writes:
> On Mon, Sep 01, 2014 at 02:05:37PM -0400, Tom Lane wrote:
>> Functionally this seems like a clear win over what we had, especially
>> since it supports using the pager. I'm inclined to think we should
>> not only apply this change but back-patch it.
> I've not used \s apart from verifying that certain patches didn't break it.
> (That "less ~/.psql_history" beats dumping thousands of lines to the tty was a
> factor.) "\s fname" is theoretically useful as an OS-independent alternative
> to "cp ~/.psql_history fname". I see too little certainty of net benefit to
> justify a minor-release change to this.
I disagree. \s to the tty is *completely broken* on all but quite old
libedit releases, cf
http://www.postgresql.org/message-id/17435.1408719984@sss.pgh.pa.us
That seems to me to be a bug worthy of back-patching a fix for.
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.)
You could certainly argue that the introduction of pager support is a
feature addition not a bug fix, but I can't really see the point of
leaving out that part of the patch in the back branches. The lack of
pager support in \s has been an acknowledged bug since forever, and I
don't think the pager calls in the new code are the riskiest part of it.
> Yikes. It's already painful to see libedit and GNU readline trash each
> other's .psql_history files; let's not add a third format.
There's no third format involved in this patch, though we'd need one if
we stopped using the underlying libraries' read/write functions, since
both those formats suck for different reasons. I agree that it might be
best if we did that, but designing and testing such a change seems well
beyond the scope of a back-patchable fix.
regards, tom lane