On Saturday 11 April 2009 10:15:44 am lists@mgreg.com wrote:
> On Apr 11, 2009, at 12:56 PM, Tom Lane wrote:
> > There is no such edge case. DROP DATABASE has to be issued while
> > connected to some database, and it won't let you drop the DB you're
> > connected to.
> >
> > And CREATE DATABASE has to be issued while connected to some database,
> > so createdb still has to have a default database to connect to. There
> > really is no state in Postgres corresponding to "connected but not
> > connected to any particular database".
> >
> > It does all hang together. You will need to lose a lot of MySQL
> > preconceptions along the way, I fear.
> >
> > regards, tom lane
>
> I think our first issue is semantics and our second is paradigm.
> Hopefully I'm simply misunderstanding what you're saying, but what
> sense does it make to have to connect to an unrelated DB in order to
> query about others?
>
> Basically, I have some applications that will simply use PG as a
> backend. That application needs to ask the engine manager (whatever
> that means in in postgres speak) and see if relevant databases already
> exist. If they don't then it needs to create them. So, how does
> needing to connect to a database before querying about existing
> databases make any sense? MySQL aside, it seems an extra constraint/
> step for naught.
>
> Perhaps I asked the wrong question in the beginning -- I do
> apologize. Maybe I should have asked for an external application that
> has the ability to talk to the PG engine. I believe John R. Pierce
> provided me with what I need in his last post -- that of listing DBs
> via a "psql -l".
I believe that assumes the 'postgres' database is present. The problem is fairly
simple no database == no connection.
>
>
> Thanks,
> Michael
--
Adrian Klaver
aklaver@comcast.net