Andreas Pflug <[EMAIL PROTECTED]> writes: > Fallback is a fine idea, but this brings up another problem I'm > currently facing: how to identify the problem the connection has from > libpq? If the problem is a wrong password, we certainly don't want to > try again. I browsed the sources over and over, but apparently there's > no machine readable return code to distinguish the reason of connection > failure apart from examining the errormessage string.
If it's a server-side failure it should have a SQLSTATE code. I think it'd be OK to look for ERRCODE_UNDEFINED_DATABASE to determine this. However that still leaves us with an issue: $ psql -U foo psql: FATAL: database "foo" does not exist The "real" problem here is that there's no user foo, but the backend is currently coded in such a way that it detects the bad implied database name first (at least in non-password-based auth methods). Not sure if this is a big problem for code that's not defaulting the database name though. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]