PGresult should store a copy of errorMessage
От | Tom Lane |
---|---|
Тема | PGresult should store a copy of errorMessage |
Дата | |
Msg-id | 18774.906400211@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-interfaces |
It seems to me that a PGresult object (returned by libpq's PQexec) ought to carry its own copy of the error message, if the status code in the object indicates an error. Currently, the error message text is only kept in the connection object, from which you extract it with PQerrorMessage(conn) after you've discovered that PQstatus(result) indicates error. This has several problems: 1. You can't interpret a PGresult in isolation; you must have access to the associated connection object. (PGresult does contain a link to PGconn, but that's never been part of the official API; there's no accessor function for it.) 2. If the PGresult is kept around while more operations are done with the PGconn, the error message stored in PGconn is no longer correct for the PGresult. This is an entirely likely scenario; in particular, checking for NOTIFY messages might change the PGconn's error message before the application is done with the PGresult. 3. It's perfectly plausible that a PGresult might outlive its source PGconn. In this situation the PGresult's conn link is a dangling pointer. We really ought to get rid of it. I would like to propose that a PGresult carry a strdup'd copy of the error message if its status indicates error, and that we add an accessor function PQerrMsg(result) that retrieves that error message. Then the definitions would be: PQerrMsg(result): error associated with a failed PGresult, or empty string if no error PQerrorMessage(conn): error from latest operation on connection, or empty string if no error which seem to me to both be useful and clear; but we should deprecate using PQerrorMessage(conn) when what you are really looking at is a PGresult. The only downside to this is a few more bytes and cycles to create or destroy a PGresult, but considering what it took to produce the PGresult I don't think the extra overhead is significant. Any objections? Can anyone think of a more suitable name than "PQerrMsg"? (If libpq were C++ code we could just overload PQerrorMessage on the argument type, but it isn't...) regards, tom lane
В списке pgsql-interfaces по дате отправления: