Re: Differentiating various OperationalError 'states' - Mailing list psycopg

From Daniele Varrazzo
Subject Re: Differentiating various OperationalError 'states'
Date
Msg-id CA+mi_8aTozXQRCkEUzquV3-FUGrFnZ8hkYUYqXhyWB-yxcRSqg@mail.gmail.com
Whole thread Raw
In response to Differentiating various OperationalError 'states'  (Mario Splivalo <mario@splivalo.hr>)
Responses Re: Differentiating various OperationalError 'states'  (Mario Splivalo <mario@splivalo.hr>)
List psycopg
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


psycopg by date:

Previous
From: Mario Splivalo
Date:
Subject: Differentiating various OperationalError 'states'
Next
From: Mario Splivalo
Date:
Subject: Re: Differentiating various OperationalError 'states'