I didn't understand the coding in GetQueryResult(); why do we check the
result status of the last returned result only?  It seems simpler to me
to check it inside the loop, but maybe there's a reason you didn't do it
like that?

Also, what is the reason we were ignoring those errors only in
"completedb" mode?  It doesn't seem like it would cause any harm if we
did it in all cases.  That means we can just not have the "completeDb"
flag at all.

Finally, I think it's better to report the "missing relation" error,
even if we're going to return true to continue processing other tables.
That makes the situation clearer to the user.

So the function would end up looking like this:

/*
 * GetQueryResult
 *
 * Process the query result.  Returns true if there's no error, false
 * otherwise -- but errors about trying to vacuum a missing relation are
 * ignored.
 */
static bool
GetQueryResult(PGconn *conn, errorOptions *erropts)
{
        PGresult    *result = NULL;

        SetCancelConn(conn);
        while ((result = PQgetResult(conn)) != NULL)
        {
                /*
                 * If errors are found, report them.  Errors about a missing 
table are
                 * harmless so we continue processing, but die for other errors.
                 */
                if (PQresultStatus(result) != PGRES_COMMAND_OK)
                {
                        char *sqlState = PQresultErrorField(result, 
PG_DIAG_SQLSTATE);

                        fprintf(stderr, _("%s: vacuuming of database \"%s\" 
failed: %s"),
                                        erropts->progname, erropts->dbname, 
PQerrorMessage(conn));

                        if (sqlState && strcmp(sqlState, 
ERRCODE_UNDEFINED_TABLE) != 0)
                        {
                                PQclear(result);
                                return false;
                        }
                }

                PQclear(result);
        }
        ResetCancelConn();

        return true;
}



-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to