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