Re: pg_upgrade if 'postgres' database is dropped

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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 12:00:46
Message-ID: CABUevEznSoDMswNdpXrGjxf7K0Y0i5eNkjuJAknrDRe1Mt9Geg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ;)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-12-06 12:12:22 Re: pg_cancel_backend by non-superuser
Previous Message Magnus Hagander 2011-12-06 11:49:29 Re: [REVIEW] pg_last_xact_insert_timestamp