Re: Differentiating various OperationalError 'states'

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: Mario Splivalo <mario(at)splivalo(dot)hr>
Cc: "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org>
Subject: Re: Differentiating various OperationalError 'states'
Date: 2014-02-04 16:52:59
Message-ID: CA+mi_8aTozXQRCkEUzquV3-FUGrFnZ8hkYUYqXhyWB-yxcRSqg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: psycopg

On Tue, Feb 4, 2014 at 3:31 PM, Mario Splivalo <mario(at)splivalo(dot)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

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Mario Splivalo 2014-02-05 12:55:02 Re: Differentiating various OperationalError 'states'
Previous Message Mario Splivalo 2014-02-04 15:31:01 Differentiating various OperationalError 'states'