begriffs open source - ai-pg/blob - full-docs/txt/role-removal.txt

   1
   2 21.4. Dropping Roles #
   3
   4    Because roles can own database objects and can hold privileges to
   5    access other objects, dropping a role is often not just a matter of a
   6    quick DROP ROLE. Any objects owned by the role must first be dropped or
   7    reassigned to other owners; and any permissions granted to the role
   8    must be revoked.
   9
  10    Ownership of objects can be transferred one at a time using ALTER
  11    commands, for example:
  12 ALTER TABLE bobs_table OWNER TO alice;
  13
  14    Alternatively, the REASSIGN OWNED command can be used to reassign
  15    ownership of all objects owned by the role-to-be-dropped to a single
  16    other role. Because REASSIGN OWNED cannot access objects in other
  17    databases, it is necessary to run it in each database that contains
  18    objects owned by the role. (Note that the first such REASSIGN OWNED
  19    will change the ownership of any shared-across-databases objects, that
  20    is databases or tablespaces, that are owned by the role-to-be-dropped.)
  21
  22    Once any valuable objects have been transferred to new owners, any
  23    remaining objects owned by the role-to-be-dropped can be dropped with
  24    the DROP OWNED command. Again, this command cannot access objects in
  25    other databases, so it is necessary to run it in each database that
  26    contains objects owned by the role. Also, DROP OWNED will not drop
  27    entire databases or tablespaces, so it is necessary to do that manually
  28    if the role owns any databases or tablespaces that have not been
  29    transferred to new owners.
  30
  31    DROP OWNED also takes care of removing any privileges granted to the
  32    target role for objects that do not belong to it. Because REASSIGN
  33    OWNED does not touch such objects, it's typically necessary to run both
  34    REASSIGN OWNED and DROP OWNED (in that order!) to fully remove the
  35    dependencies of a role to be dropped.
  36
  37    In short then, the most general recipe for removing a role that has
  38    been used to own objects is:
  39 REASSIGN OWNED BY doomed_role TO successor_role;
  40 DROP OWNED BY doomed_role;
  41 -- repeat the above commands in each database of the cluster
  42 DROP ROLE doomed_role;
  43
  44    When not all owned objects are to be transferred to the same successor
  45    owner, it's best to handle the exceptions manually and then perform the
  46    above steps to mop up.
  47
  48    If DROP ROLE is attempted while dependent objects still remain, it will
  49    issue messages identifying which objects need to be reassigned or
  50    dropped.