Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Дата
Msg-id 5ed37b140912161714o6a970f7eoedccf7b5e6fa783c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior  (Chris Travers <chris@metatrontech.com>)
Ответы Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Hi Tom and everyone else;

After significant additional research this is what I have turned up:

1) The problem was a problem in DBD::Pg which didn't quite succeed in
setting the connection state to 08006.  I have submitted a patch for
that to the DBD::Pg project.

2) As of 8.1, tshark shows that the server does send the SQLSTATE to
the client regarding why the login fails (for example 3D000 in the
case of bad db name).  Libpq as far as I can tell (from reading the
code) doesn't do anything with this code.  Certainly there seems to be
no exposure of the SQLSTATE to anything as it relates to a failed
connection attempt.  I could be missing something because I am not
extremely familiar with the libpq codebase, but it seems that the
value is just discarded.

Are there any plans to expose the SQLSTATE from a failed connection
attempt upwards through the library?  (I would be happy to try to
write a patch but you probably don't want my C code in your library.)

Best Wishes,
Chris Travers

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

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: BUG #5244: Attempting to rollback to a savepoint after receiving an error with state 55000 the process hangs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior