Hi Alvaro,

Thanks for your review, now the new patch with the error message in PG style is attached.

On 2020-02-28 8:03 a.m., Alvaro Herrera wrote:
On 2020-Feb-18, David Zhang wrote:

3. I think a better way to resolve this issue will still be the solution
with an extra %m, which can make the error message much more informative to
the end users.
Yes, agreed.  However, we use a style like this:

                pg_log_error("could not print tuples: %m");

--
David

Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 4b2679360f..9ffb1ef10f 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -855,6 +855,7 @@ static bool
 PrintQueryTuples(const PGresult *results)
 {
        printQueryOpt my_popt = pset.popt;
+       bool result = true;
 
        /* one-shot expanded output requested via \gx */
        if (pset.g_expanded)
@@ -872,6 +873,11 @@ PrintQueryTuples(const PGresult *results)
                        disable_sigpipe_trap();
 
                printQuery(results, &my_popt, fout, false, pset.logfile);
+               if (ferror(fout))
+               {
+                       pg_log_error("could not print tuples: %m");
+                       result = false;
+               }
 
                if (is_pipe)
                {
@@ -882,9 +888,16 @@ PrintQueryTuples(const PGresult *results)
                        fclose(fout);
        }
        else
+       {
                printQuery(results, &my_popt, pset.queryFout, false, 
pset.logfile);
+               if (ferror(pset.queryFout))
+               {
+                       pg_log_error("could not print tuples: %m");
+                       result = false;
+               }
+       }
 
-       return true;
+       return result;
 }
 
 

Reply via email to