Re: pg_upgrade if 'postgres' database is dropped - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_upgrade if 'postgres' database is dropped
Date
Msg-id CA+TgmoaDmjC2A87NH521YZ_N9Zu5p_+0naaAbknVuDH3mD16Ew@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade if 'postgres' database is dropped  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Tue, Dec 6, 2011 at 7:00 AM, Magnus Hagander <magnus@hagander.net> wrote:
> Seems reasonably clean to me. Not sure what would be unclean about it?

Based on this feedback, I went ahead and committed my previous patch.
This means that if pg_upgrade wants to accept a --maintenance-db
option, it will be able to pass it through to any other commands it
invokes.  And if it doesn't do that, vacuumdb et. al. should still
work anyway, as long as either template1 or postgres is accessible.

>>> > Also, if we are going to add this flag, we should have pg_dumpall use it
>>> > too and just deprecate the old options.
>>>
>>> I thought about that, but couldn't think of a compelling reason to
>>> break backward compatibility.
>
> Adding it to pg_dumpal lwithout removing the old one doesn't cause
> backwards compatibility break. Then mark the old one as deprecated,
> and remove it a few releases down the road. We can't keep every switch
> around forever ;)

I'm not really sold on tinkering with pg_dumpall; if it ain't broke,
don't fix it.  But we can bikeshed about it if we like.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade if 'postgres' database is dropped
Next
From: Magnus Hagander
Date:
Subject: Re: [DOCS] Moving tablespaces