Re: potential bug in psql

Szymon Guz <mabewlun(at)gmail(dot)com> writes:
> when I run `\s` in psql, I get the nice list of queries with an error at
> the end:

> "\s
> could not save history to file "/dev/tty": No such file or directory"

Well, that's interesting ... what version of which readline library are
you using?

Presumably what is happening is that write_history is writing out the data
okay (since you saw it) but then returning nonzero errno. This is a bit
odd since we've not heard other complaints. strace'ing psql while it does
this might be interesting.

We may have to re-revisit the question of how we detect errors in
write_history. Some of the back story can be found here:
http://www.postgresql.org/message-id/flat/3B715BA0-CC81-4B3C-9174-5357129AABB7(at)justatheory(dot)com
and here:
http://www.postgresql.org/message-id/flat/ce92d7150608210927y44fb02bcw612dd75995e1d438(at)mail(dot)gmail(dot)com

Despite those efforts, I find that on OS X Mavericks, \s no longer works
at all with libedit:

regression=# \s
could not save history to file "/dev/tty": Operation not permitted

The reason becomes clear on comparing source for the two versions:
http://www.opensource.apple.com/source/libedit/libedit-3/libedit/history.c
http://www.opensource.apple.com/source/libedit/libedit-39/src/history.c

Somewhere in the last few releases, Apple "improved" history_save() so
that it not only does a fchmod() on the target file, but refuses to write
anything to the file if that fails. I don't know if this was their own
idea or is something they got from upstream libedit development (though
most likely the latter). It's unsurprising that an fchmod on /dev/tty
would fail --- you don't really own that file.

I wonder if we should just abandon the idea that \s to /dev/tty is
possible. It's certainly never going to work anymore on libedit, and
I'd bet against getting the libedit developers to revert this change;
they probably think it's a security fix.

Another idea would be to reimplement \s as "do a normal history file save,
then cat the history file contents to /dev/tty". This would have a couple
of benefits: we could interpose the pager program instead of just doing
"cat", and conceivably we could undo the encoding that libedit puts on the
file entries (though I'm not sure exactly how we'd figure out what it is).

TBH, though, \s doesn't seem to me to be anywhere near worth the amount
of work we've already put into it, let alone a major new implementation
effort. Who's for just removing the command altogether?

regards, tom lane