On Tue, Feb 4, 2014 at 3:31 PM, Mario Splivalo <mario@splivalo.hr> wrote:
> Is there a better (more proper) way do figure out what went wrong when
> OperationalException is thrown?
Apparently no, or not always: an error such as connection refused
(purely client side) doesn't generate any errcode (e.g. grep for
"could not connect to server" into postgres source
src/interfaces/libpq/fe-connect.c).
An error returned by the backend may have a sqlcode set though:
grepping for "no pg_hba.conf entry for host" into
src/backend/libpq/auth.c shows an error code is set indeed: in this
case maybe psycopg is doing the wrong thing.
So maybe we could present some more informations through the
exception's sqlstate, but looking at the available error codes I
wouldn't expect much more than a classification among "invalid auth",
"bad password", "any other unknown reason".
-- Daniele