]> granicus.if.org Git - postgresql/commit
Clean up some psql issues around handling of the query output file.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 3 Dec 2015 19:28:58 +0000 (14:28 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 3 Dec 2015 19:29:28 +0000 (14:29 -0500)
commit344cdff2c1541e7a1249299a33723aabeafa0b0c
treefe16426718eb6f1abd388ba0db94c31aa8e80f38
parentf15b820a5c60b10f3ac1b2fdb37d534ecb0a4bf8
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