Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Date
Msg-id AANLkTinqDBZBVQDbWps=cS_xHC=iW1d8o0TM-=Y3gBmm@mail.gmail.com
Whole thread Raw
In response to Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This is about like arguing that pg_dump and pg_upgrade should still work
> after you've done "delete from pg_proc;".  Superusers are assumed to
> know what they're doing and not break fundamental operations.

No, it isn't like that at all.  You've made that argument in the past,
and it carries no water with me at all.  There's no help for the fact
that direct modification of the system catalog contents can
fundamentally break things, but DDL commands should not.  I'm willing
to reserve judgment on whether ALTER DATABASE .. SET ROLE should be
disallowed, or whether it should be made to not break things, but
blaming the DBA for shooting himself with the loaded foot-gun we
thoughtfully provided is unreasonable.

And in fact it strikes me that we might not have much choice about how
to fix this.  I think we are not going to retroactively change the
behavior of ALTER DATABASE .. SET ROLE in a released version, but yet
we do, I think, want to make pg_upgrade work.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: create tablespace fails silently, or succeeds improperly
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED