| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCHES] default database creation with initdb |
| Date: | 2005-06-20 13:35:52 |
| Message-ID: | 1178.1119274552@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andreas Pflug <pgadmin(at)pse-consulting(dot)de> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-06-20 14:01:20 | Re: quote_boolean() and friends missing |
| Previous Message | Tom Lane | 2005-06-20 13:19:14 | Re: [PATCHES] default database creation with initdb |