On Jan6, 2011, at 05:08 , Tom Lane wrote: > 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.
I explained up-thread why, in my situation, doing this *is* a perfectly good idea. You have neither offered an alternative solution nor argued why *exactly* this is supposed to be such a bad idea, other than the obvious "it breaks pg_upgrade". Which isn't a very convincing argument that this isn't simply a pg_upgrade bug... To reiterate: I did ALTER DATABASE SET ROLE to allow different developers to work on the same database without the permission system getting into their way. Without that, objects created by one developer couldn't be modified by another, which obviously didn't work very well... > 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. Nothing was hosed here. I simply solved a very real problem with the tools made available by postgres. Telling me after *years* of this solution working perfectly, and after I discovered that a *new* tool doesn't handle the situation well, that I deliberately hosed things is downright unfriendly from where I stand. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
