From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)surnet(dot)cl> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [ADMIN] Permissions not removed when group dropped |
Date: | 2005-05-15 21:48:56 |
Message-ID: | 3358.1116193736@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
Alvaro Herrera <alvherre(at)surnet(dot)cl> writes:
> Additionally we need to think what should happen if the user is the
> grantor of some privilege. I think we should warn in RESTRICT mode, and
> in CASCADE, revoke the privilege from the grantee.
You mean "fail in RESTRICT mode", no?
> Hmm. We could implement something like "DROP USER LOCALLY [CASCADE |
> RESTRICT]", which would be a very misleading name for operations 2-4
> above. Additionally, if the user doesn't have references in other
> databases, drop the user itself. (Note it's inconsistent.)
I'd go for something more like "DROP OWNED OBJECTS", which'd be just
the stuff internal to the current database (owned objects and ACL
entries). You don't need to drop group memberships per-database.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2005-05-16 00:51:51 | Re: DB replicators comparison; (vs. DB upgrade via pg_dump) |
Previous Message | Alvaro Herrera | 2005-05-15 21:42:53 | Re: [ADMIN] Permissions not removed when group dropped |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-05-16 04:04:31 | Re: [ADMIN] Permissions not removed when group dropped |
Previous Message | Alvaro Herrera | 2005-05-15 21:42:53 | Re: [ADMIN] Permissions not removed when group dropped |