[Moved to -hackers] On Sat, May 14, 2005 at 11:32:23AM -0400, Tom Lane wrote:
> So what we've got [for DROP USER] is: > > 1. Reject if any references to user from within other databases > (implementation restriction). > > 2. Reject if user owns any databases or tablespaces (safety feature). > > 3. If CASCADE mode, drop any owned objects within the current database; > if RESTRICT mode, reject if there are owned objects within the current > database. > > 4. Auto-drop any remaining references (ACLs and group memberships). > > 5. Drop the user itself. Sounds reasonable. 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. > The main problem I see with this is that if you do have a user you want > to get rid of who owns objects in multiple databases, it's still mighty > hard to do it. It'd be nice to have some kind of command that either > drops or reassigns ownership of everything the user has in the current > database. Then you could use that repeatedly until you'd reached a > point where DROP USER would work. 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.) For DROP TABLESPACE, I think we should also provide some sort of DROP LOCALLY, that drops all objects in the current database. (Suggestions for the exact spelling of the option are welcome.) -- Alvaro Herrera (<alvherre[a]surnet.cl>) "La gente vulgar solo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo" ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
