Re: dropping a user causes pain (#2)

ISTM there's a difference between an object without an (exisiting) owner 
and an object whose owner doesn't currently have the privileges required 
to create it, although maybe there's a good case for a script to detect 
the latter as a part of a good administrator's arsenal of tricks in 
keeping things sane and clean.

andrew

Peter Eisentraut wrote:

>Tom Lane writes:
>
>  
>
>>The advantage here is that the sysid assigned to the user would remain
>>present in pg_shadow and couldn't accidentally be assigned to a new
>>user.  This would prevent the problem of new users "inheriting"
>>permissions and even object ownership from deleted users due to chance
>>coincidence of sysid.
>>    
>>
>
>But how does one actually get rid of the privileges?
>
>Btw., the problem is going to get worse if we get nested roles, roles with
>grant options, and possibly other parts of the enhanced privilege
>facilities.  For example, if you remove a user from a role/group, you
>would need to search the entire database cluster for any privileges
>granted through that group that this user had used to create some kind of
>permanent state.  I'm not sure if we want to cover all of these cases with
>various "this link no longer exists" flags, especially since later on the
>link could be reestablished.
>
>  
>