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
