Chris Travers <chris@metatrontech.com> writes:
> 2) As of 8.1, tshark shows that the server does send the SQLSTATE to
> the client regarding why the login fails (for example 3D000 in the
> case of bad db name). Libpq as far as I can tell (from reading the
> code) doesn't do anything with this code. Certainly there seems to be
> no exposure of the SQLSTATE to anything as it relates to a failed
> connection attempt. I could be missing something because I am not
> extremely familiar with the libpq codebase, but it seems that the
> value is just discarded.
Yeah. The problem is that the only infrastructure libpq has for returning
individual error message fields (like the SQLSTATE) is associated with a
PGresult, and there's no PGresult for a connection failure. I see no
easy way to fix that without incompatible changes in libpq's API.
This is related to the fact that errors detected internally in libpq
generally lack SQLSTATEs. Part of the reason that fixing that has been
so low-priority is that in many cases there's no existing API whereby
they could be returned anyhow. It's been on the TODO list since 7.4,
but nobody has cared to tackle it.
regards, tom lane
