[psycopg] psycopg2: distinguishing connect failures through exception handling

Поиск
Список
Период
Сортировка
От Stephen Quintero
Тема [psycopg] psycopg2: distinguishing connect failures through exception handling
Дата
Msg-id CAJ_2OS9zDN7-vJVSLSrAX9-f9KTMyzb6NYbHREBUgFg4CAHrdw@mail.gmail.com
обсуждение исходный текст
Ответы Re: [psycopg] psycopg2: distinguishing connect failures throughexception handling  ("Karsten Hilbert" <Karsten.Hilbert@gmx.net>)
Список psycopg
Hi Folks,

My first email here.  I am using psycopg2 to remotely verify a postgres server is up, and separately that it is accessible given a particular user/password/database.  This is done using psycopg2.connect(args...).  The use case is automated deployment of the docker postgres container, where I wish to distinguish postgres service is up from postgres service cannot be accessed (e.g., with your user/password/database), from postgres service is down, in order to verify the container deployment.

It seems the psycopg2.OperationalError exception is thrown in a variety of circumstances:  database does not exist, authentication failed, no password supplied, etc.  But, the exception pgcode and pgerror are not set, evidently unless there is a successful connect.  This leaves me in the position of distinguishing failures based on the error message string, e.g. fe_sendauth: no password supplied or FATAL:  password authentication failed for user "<val>"

This does not seem like a reliable method, one certain to work in the future, and known to work now across myriad versions of postgres (outside the scope of my practical testing).

I have these two questions.  Is this understanding correct?  Is there a reliable means to distinguish the types of connect failures using psycopg2?

Thank you for your time.

Best regards,

Stephen Quintero

В списке psycopg по дате отправления:

Предыдущее
От: Karsten Hilbert
Дата:
Сообщение: Re: [psycopg] Changing set_session implementation
Следующее
От: "Karsten Hilbert"
Дата:
Сообщение: Re: [psycopg] psycopg2: distinguishing connect failures throughexception handling