Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur |
Дата | |
Msg-id | CAB7nPqR8Fus04h=+KUDidBqxmsK0iKHW64ux_Qqo38oL7WcW3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Ответы |
Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur
|
Список | pgsql-hackers |
On Thu, May 18, 2017 at 5:05 PM, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > So, how about trying connection to the next host when the class code is neither 28, 3D, nor 42? > > Honestly, I'm not happy with this approach, for a maintenance reason that others are worried about. Besides, when theconnection target is not postgres and returns invalid data, no SQLSTATE is available. I'm sorry to repeat myself, butI believe PgJDBC's approach is practically good. If you think the SQLSTATE is the only way to go, I will put up withit. It would be disappointing if nothing is done. FWIW, I am of the opinion to not have an implementation based on any SQLSTATE codes, as well as not doing something similar to JDBC. Keeping things simple is one reason, a second is that the approach taken by libpq is correct at its root. -- Michael
В списке pgsql-hackers по дате отправления: