Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian <br...@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.
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
