Re: Patch for psql History Display on MacOSX - Mailing list pgsql-hackers
From | Stepan Rutz |
---|---|
Subject | Re: Patch for psql History Display on MacOSX |
Date | |
Msg-id | FB607D3B-AFD3-4ACE-9CAB-C65A0E77C65A@gmx.de Whole thread Raw |
In response to | Re: Patch for psql History Display on MacOSX (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Patch for psql History Display on MacOSX
|
List | pgsql-hackers |
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
pgsql-hackers by date: