Re: DROP ROLE dependency tracking ...

Alvaro Herrera wrote:
> Hans-Juergen Schoenig wrote:
>
>   
>> test=# create role xy LOGIN;
>> CREATE ROLE
>>
>> test=# grant connect on database test to xy;
>> GRANT
>>
>> test=# drop role xy;
>> ERROR:  role "xy" cannot be dropped because some objects depend on it
>> DETAIL:  access to database test
>>
>> this is a totally fresh instance --- all i did was creating a db called  
>> "test".
>> failing would make sense if i would the owner of an object but i fact i  
>> don't own anything.
>>     
>
> But in some cases you might not want to lose the information associated
> to the grants you've done.  That's why we have REASSIGN OWNED.
>
> Hmm, but then there's no way to lose it, even if you do want that.  DROP
> OWNED does not touch grants (which is per design), but we don't have
> DROP ROLE CASCADE.  So maybe there's a functionality gap here ...
>
>   

when thinking of REASSIGNED OWNED people tend to think about tables 
rather than about CONNECT rights.
i would suggest to make DROP ROLE just kill the role unless there is a 
real object depending on it.
i would not see a permission to be an object. what do you think?
   many thanks,
      hans



-- 
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com