From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 09:36:47 |
Message-ID: | 42B68E2F.6080806@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
>>
>>
>> The decision which files should be changed must be taken. e.g.
>> createdb, dropdb will use template1 hardcoded. Is it acceptable that
>> those tools fail if the "postgres" database isn't present any more?
>>
>>
>
> How about template1 as a fallback?
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. I have the same
problem in pgAdmin, where I try to give extended messages like
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/trunk/pgadmin3/docs/en_US/hints/conn-listen.html?rev=4056&view=markup
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-06-20 09:41:07 | Re: [PATCHES] default database creation with initdb |
Previous Message | Andrew Dunstan | 2005-06-20 09:26:42 | Re: [PATCHES] default database creation with initdb |