Thanks Tom. This would help the poor mac-osx guys like me. I guess this is not 
that important because no one runs a production server on OS-X.  

Back patching to 9.3 won’t work as is, some minor conflict was there. 

Anyway, I am sure the iteration used in encode_history and decode_history in 
input.c does not work on libedit.

Regards from cologne,

Am 01.09.2014 um 20:05 schrieb Tom Lane <>:

> Stepan Rutz <> writes:
>> Attached is a very trivial patch as a basis for discussion that at least 
>> makes \s (show history) work in psql on Macs. Macs uses libedit, which has a 
>> libreadline interface. 
> Hm.  The $64 question here is whether we can assume that history_get()
> exists and works compatibly in every interesting version of libreadline
> and libedit.
> I poked into the oldest version of GNU readline I could find, 4.0
> (released in 1999), and that has it.  The oldest libedit I have around
> is the one that came with OSX 10.4 (the CVS marker in readline.h from
> that says 2004/01/17).  That has it too.  So that looks pretty good.
> The readline code says that the argument ranges from "history_base"
> up, not from 1 up as this patch assumes.  And it looks like history_base
> can change once the max number of stored lines is exceeded, so we can't
> assume that 1 is good enough.  Fortunately, the global variable
> history_base also exists in both libraries (though it looks like it
> never changes from 1 in libedit).
> 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?  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.
> There are a couple other minor bugs and some cosmetic things I don't like
> in this patch, but I'm willing to fix it up and commit it if there
> are not objections.
>                       regards, tom lane
> -- 
> Sent via pgsql-hackers mailing list (
> To make changes to your subscription:

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to