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