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.
>
>
>