Re: Equivalent of PQresultErrorField for PGconn?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Equivalent of PQresultErrorField for PGconn?
Date: 2003-07-28 07:49:10
Message-ID: 3233.1059378550@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I seem to be missing an equivalent of PQresultErrorField() that operates
> on a PGconn object (like PQerrorMessage() does). This would be useful to
> detect errors that occur outside of a statement execution.

Yeah. I thought about that, but the infrastructure is not there:
libpq's internal error reports would have to be restructured to deliver
multiple fields, in the same way as we have done in the backend. There
was not time to make it happen for 7.4.

Looking at the spec's list of SQLSTATE codes, it seems clear that they
intend SQLSTATE to cover client-library-detected errors as well as
server-detected ones. So it would make sense to tackle this project
for 7.5.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-07-28 07:49:41 Passing server_encoding to the client is not future-proof
Previous Message Peter Eisentraut 2003-07-28 07:47:39 SQLSTATEs for warnings