Should psql exit when the log file can't be written into?

  Hi,

Following last week's commit 344cdff :

Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:    Thu Dec 3 14:28:58 2015 -0500

    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.
    [...]

I notice that --log-file also reports an error but continues nonetheless
if the file can't be opened.
The attached trivial patch makes it fail and exit instead.

Also there's the fact that once opened, psql currently ignores errors
when writing to that file.

Without going as far as tracking every write in print.c,  there are at
least two places in the code where it would be easy to abort the
processing, should we want to, at the beginning of SendQuery() and
PSQLexec(). The code here looks like:

  if (pset.logfile)
  {
    fprintf(pset.logfile,
    _("********* QUERY **********\n"
      "%s\n"
      "**************************\n\n"), query);
    fflush(pset.logfile);
  }

At this point if fprintf() returns a negative value, maybe we should
error out and exit rather than ignore it.
Or at least do that when ON_ERROR_STOP is on?

The typical case when it might happen is a disk full condition.
In this scenario, I can imagine a psql exit(1) being both desirable
or not. Certain users could be satisfied that a script went to completion
even in this client-side degraded state.
But other users could be unhappy about the queries being executed
without leaving the expected traces, if the logging part happens to
be essential to them.


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite