[HACKERS] Equivalent of PQresultErrorField for PGconn?

[Peter Eisentraut]

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.

(One particular case I'm looking at is the message fe_sendauth: no
password supplied, which clients look at to detect if they need to send a
password.)

-- 
Peter Eisentraut   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [HACKERS] Equivalent of PQresultErrorField for PGconn?

[Tom Lane]

Peter Eisentraut [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster