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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
