Tom Lane wrote: > Robert Haas <[email protected]> writes: > > On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian <[email protected]> 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.
Yep. We should probably make a decision on foot-guns and be consistent, at least. Doing it half-way isn't helping anyone. -- Bruce Momjian <[email protected]> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
