Skip site navigation (1) Skip section navigation (2)

PGresult should store a copy of errorMessage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-interfaces(at)postgreSQL(dot)org
Subject: PGresult should store a copy of errorMessage
Date: 1998-09-21 17:50:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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

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 by date

Next:From: Deslippe, MichaelDate: 1998-09-21 17:54:25
Subject: subscribe interfaces
Previous:From: jkraaiDate: 1998-09-21 15:06:48

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group