Further improve documentation of the role-dropping process.

In commit 1ea0c73c2 I added a section to user-manag.sgml about how to drop
roles that own objects; but as pointed out by Stephen Frost, I neglected
that shared objects (databases or tablespaces) may need special treatment.
Fix that.  Back-patch to supported versions, like the previous patch.

diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 1952cac6510291ba6a040446b868fcaa65b6957f..d1b6e5990dbfd953ab93ad0551d30f169bef6584 100644 (file)
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -431,17 +431,23 @@ ALTER TABLE bobs_table OWNER TO alice;
 
    Alternatively, the  command can be
    used to reassign ownership of all objects owned by the role-to-be-dropped
-   to a single other role.  Because REASSIGN OWNED can only
-   access objects in the current database, it is necessary to run it in each
-   database that contains objects owned by the role.
+   to a single other role.  Because REASSIGN OWNED cannot access
+   objects in other databases, it is necessary to run it in each database
+   that contains objects owned by the role.  (Note that the first
+   such REASSIGN OWNED will change the ownership of any
+   shared-across-databases objects, that is databases or tablespaces, that
+   are owned by the role-to-be-dropped.)
   
 
   
    Once any valuable objects have been transferred to new owners, any
    remaining objects owned by the role-to-be-dropped can be dropped with
-   the  command.  Again, this command can
-   only access objects in the current database, so it is necessary to run it
-   in each database that contains objects owned by the role.
+   the  command.  Again, this command cannot
+   access objects in other databases, so it is necessary to run it in each
+   database that contains objects owned by the role.  Also, DROP
+   OWNED will not drop entire databases or tablespaces, so it is
+   necessary to do that manually if the role owns any databases or
+   tablespaces that have not been transferred to new owners.
   
 
   
@@ -456,7 +462,6 @@ ALTER TABLE bobs_table OWNER TO alice;
   
    In short then, the most general recipe for removing a role that has been
    used to own objects is:
-
   
 
 REASSIGN OWNED BY doomed_role TO successor_role;
@@ -465,6 +470,12 @@ DROP OWNED BY doomed_role;
 DROP ROLE doomed_role;
 
 
+  
+   When not all owned objects are to be transferred to the same successor
+   owner, it's best to handle the exceptions manually and then perform
+   the above steps to mop up.
+  
+
   
    If DROP ROLE is attempted while dependent objects still
    remain, it will issue messages identifying which objects need to be