Hi,
since the dropped user is very unlikely to be resurrected, the correct answer would be to remove all dangling permissions on the existing objects. Using a sequence would only clutter the system with unused grants.
What about ownership? would that mean you want to delete the object?
Since DROP USER is only rarely used, it would be okay if this operation is expensive.
The problem is not the drop being expensive. The problem is that tables are managed withing a database, and you cannot access a database without connecting to it, and it is not an option to connect to other databases to do such a thing on any command.
So when you drop a user, you do not have access to acl so as to fix them (i.e. removing dandling permissions). That may be done on the current
database, but that is all.
Think of the system. That would mean deleting/fixing all files owned by a user when the user is removed, on whatever partition, maybe not even mounted on the host. Not really possible, and not a good idea to try...
So it looks much simpler to fix the real issue by avoiding the userid to be reused. The dandling permission cost is low.
Also, I would not be happy if deleting a user would mean deleting all objects owned by that user, esp. as I cannot know simply what they are.
At least a select statement to gather these dangling permissions should be available in the documentation.
It is a per database stuff: you must do it for every database. This very query is in the todo list of my pgadvisor stuff (see http://pg-advisor.projects.postgresql.org/). However I need some non available support from the backend that was rejected when I submitted
a patch (8 lines of code:-). So it is unlikely to be added soon.
PS: Btw: I seem to be unable to locate the TODO-list that should be referenced before posting a bug-report. Any hints?
simply follow "bug reporting guidelines" on http://www.postgresql.org/ ?
-- Fabien COELHO _ http://www.cri.ensmp.fr/~coelho _ [EMAIL PROTECTED] CRI-ENSMP, 35, rue Saint-Honoré, 77305 Fontainebleau cedex, France phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08} ________ All opinions expressed here are mine _________ ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
