Noah Misch <n...@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.1408719...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers