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, Stepan Am 01.09.2014 um 20:05 schrieb Tom Lane <t...@sss.pgh.pa.us>: > Stepan Rutz <stepan.r...@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
smime.p7s
Description: S/MIME cryptographic signature
