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

From Tom Lane
Subject Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Date
Msg-id 24698.1294286901@sss.pgh.pa.us
Whole thread Raw
In response to Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Bruce Momjian <bruce@momjian.us>)
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Andrew Dunstan <andrew@dunslane.net>)
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Robert Haas <robertmhaas@gmail.com>)
Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I think pg_dumpall would have failed with this setup too, so I don't see
>> this as a pg_upgrade bug, nor something that I am willing to risk adding
>> to pg_upgrade.

> If adding RESET SESSION AUTHORIZATION fixes the bug, I think we should
> consider doing that.

I think an appropriate response would be to prevent ALTER DATABASE SET
ROLE.  I really cannot believe that there are any situations where
that's a good idea.

Or we could take the approach somebody was just espousing about 

> Our job is to prevent the user from *accidentally*
> shooting themselves in the foot.

If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it.  But it's not
our job to try to work around it, either.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE
Next
From: Bruce Momjian
Date:
Subject: Re: Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE