Re: Patch for psql History Display on MacOSX

Thanks Tom. This would help the poor mac-osx guys like me. I guess this is not that important because no one runs a
productionserver 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,
Stepan


Am 01.09.2014 um 20:05 schrieb Tom Lane <tgl@sss.pgh.pa.us>:

> Stepan Rutz <stepan.rutz@gmx.de> 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 (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers