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

From Bruce Momjian
Subject Re: pg_upgrade if 'postgres' database is dropped
Date
Msg-id 201112061334.pB6DYuw02399@momjian.us
Whole thread Raw
In response to Re: pg_upgrade if 'postgres' database is dropped  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander wrote:
> On Thu, Nov 3, 2011 at 11:20, Bruce Momjian <bruce@momjian.us> wrote:
> > Robert Haas wrote:
> >> On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> > Robert Haas wrote:
> >> >> >> > If nobody objects, I'll go do that. ?Hopefully that should be enough
> >> >> >> > to put this problem to bed more or less permanently.
> >> >> >>
> >> >> >> All right, I've worked up a (rather boring and tedious) patch to do
> >> >> >> this, which is attached.
> >> >> >
> >> >> > I wonder if we should bother using a flag for this. ?No one has asked
> >> >> > for one, and the new code to conditionally connect to databases should
> >> >> > function fine for most use cases.
> >> >>
> >> >> True, but OTOH we have such a flag for pg_dumpall, and I've already
> >> >> done the work.
> >> >
> >> > Well, every user-visible API option has a cost, and I am not sure there
> >> > is enough usefulness to overcome the cost of this.
> >>
> >> I am not sure why you think this is worth the time it takes to argue
> >> about it, but if you want to whack the patch around or just forget the
> >> whole thing, go ahead. ?The difference between what you're proposing
> >> and what I'm proposing is about 25 lines of code, so it hardly needs
> >> an acre of justification. ?To me, making the tools consistent with
> >> each other and not dependent on the user's choice of database names is
> >> worth the tiny amount of code it takes to make that happen.
> >
> > Well, it would be good to get other opinions on this. ?The amount of
> > code isn't really the issue for me, but rather keeping the user API as
> > clean as possible.
> 
> Seems reasonably clean to me. Not sure what would be unclean about it?
> Are you saying we need to explain the concept of maintenance db
> somewhere in the docs?
> 
> >> > 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 ;)

OK, good.  I will work on this.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Florian Weimer
Date:
Subject: Re: Large number of open(2) calls with bulk INSERT into empty table
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade if 'postgres' database is dropped