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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Date: 2010-12-12 23:16:50
Message-ID: AANLkTinqDBZBVQDbWps=cS_xHC=iW1d8o0TM-=Y3gBmm@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 12, 2010 at 11:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-12 23:20:52 Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Previous Message Tom Lane 2010-12-12 23:10:41 Re: create tablespace fails silently, or succeeds improperly