Re: pg_upgrade if 'postgres' database is dropped

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade if 'postgres' database is dropped
Date: 2011-12-06 13:34:55
Message-ID: 201112061334.pB6DYuw02399@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander wrote:
> On Thu, Nov 3, 2011 at 11:20, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Robert Haas wrote:
> >> On Wed, Nov 2, 2011 at 8:31 PM, Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-12-06 13:43:07 Re: pg_upgrade if 'postgres' database is dropped
Previous Message Azghar Hussain 2011-12-06 12:37:04 Recover data....