Re: Differentiating various OperationalError 'states'
От | Daniele Varrazzo |
---|---|
Тема | Re: Differentiating various OperationalError 'states' |
Дата | |
Msg-id | CA+mi_8aTozXQRCkEUzquV3-FUGrFnZ8hkYUYqXhyWB-yxcRSqg@mail.gmail.com обсуждение исходный текст |
Ответ на | Differentiating various OperationalError 'states' (Mario Splivalo <mario@splivalo.hr>) |
Ответы |
Re: Differentiating various OperationalError 'states'
|
Список | 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 по дате отправления: