Clean up some psql issues around handling of the query output file.
authorTom Lane
Thu, 3 Dec 2015 19:29:07 +0000 (14:29 -0500)
committerTom Lane
Thu, 3 Dec 2015 19:29:29 +0000 (14:29 -0500)
commit07338cb7425ee661ea2b80c1a3826bee1bc1a1de
tree952df766c4d59739d044bd0b516cdb00cbdfda1e
parent28bfdc581a552e2a3b1f0faded352188559e5aca
Clean up some psql issues around handling of the query output file.

Formerly, if "psql -o foo" failed to open the output file "foo", it would
print an error message but then carry on as though -o had not been
specified at all.  This seems contrary to expectation: a program that
cannot open its output file normally fails altogether.  Make psql do
exit(1) after reporting the error.

If "\o foo" failed to open "foo", it would print an error message but then
reset the output file to stdout, as if the argument had been omitted.
This is likewise pretty surprising behavior.  Make it keep the previous
output state, instead.

psql keeps SIGPIPE interrupts disabled when it is writing to a pipe, either
a pipe specified by -o/\o or a transient pipe opened for purposes such as
using a pager on query output.  The logic for this was too simple and could
sometimes re-enable SIGPIPE when a -o pipe was still active, thus possibly
leading to an unexpected psql crash later.

Fixing the last point required getting rid of the kluge in PrintQueryTuples
and ExecQueryUsingCursor whereby they'd transiently change the global
queryFout state, but that seems like good cleanup anyway.

Back-patch to 9.5 but not further; these are minor-enough issues that
changing the behavior in stable branches doesn't seem appropriate.
src/bin/psql/command.c
src/bin/psql/common.c
src/bin/psql/common.h
src/bin/psql/copy.c
src/bin/psql/print.c
src/bin/psql/print.h
src/bin/psql/startup.c