On Saturday 11 April 2009 10:15:44 am lists@xxxxxxxxx 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@xxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
