Re: Patch for psql History Display on MacOSX
От | Tom Lane |
---|---|
Тема | Re: Patch for psql History Display on MacOSX |
Дата | |
Msg-id | 17129.1409603277@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Patch for psql History Display on MacOSX (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Patch for psql History Display on MacOSX
Re: Patch for psql History Display on MacOSX |
Список | pgsql-hackers |
I wrote: > Stepan Rutz <stepan.rutz@gmx.de> writes: >> Anyway, I am sure the iteration used in encode_history and decode_history in input.c does not work on libedit. > Yeah, I noticed your comment about that. That seems odd; a look at the > Apple libedit sources suggests it should work. I was just about to trace > through the logic and try to see what's happening. Sigh ... the answer is that libedit has the direction of traversal backwards compared to libreadline. If you replace next_history() by previous_history() in those loops, then it works as expected. > The reason nobody noticed is possibly that libedit doesn't actually need > the newline-encoding hack. Indeed, that's the reason. > However, we should probably fix the loops if > they aren't working as expected on libedit, just in case somebody tries > to copy the logic for some other purpose. We should either do that, or document what's actually going on here. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: