Re: Patch for psql History Display on MacOSX

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.
>
> One thing worth thinking about: should we use a history_get() loop
> like this for *all* \s commands, even when the target file is a
> regular file not /dev/tty?

+1 for printing the same bytes regardless of destination.

> libedit's version of write_history does
> not write the history "in the clear" exactly, which you would think
> is the behavior wanted when saving a command history for any purpose
> other than updating ~/.psql_history. Such a change would break a
> workflow that involves doing \s to some random file and then copying
> that file to ~/.psql_history, but I find it hard to fathom why anyone
> would do that.

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.

On Mon, Sep 01, 2014 at 04:27:57PM -0400, Tom Lane wrote:

[history encoding change discussion]

> 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.

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. Long-term, psql
should cease relying on the history library to serialize and deserialize its
history file. psql can then understand both formats, rewrite in the original
format, and use GNU format for new files.

Thanks,
nm