giving
    roles being used as SQL roles the <literal>INHERIT</literal> attribute, while
    giving roles being used as SQL users the <literal>NOINHERIT</literal> attribute.
    However, <productname>PostgreSQL</productname> defaults to giving all roles
    the <literal>INHERIT</literal> attribute, for backward compatibility with pre-8.1
    releases in which users always had use of permissions granted to groups
    they were members of.
   </para>
  </note>

  <para>
   The role attributes <literal>LOGIN</literal>, <literal>SUPERUSER</literal>,
   <literal>CREATEDB</literal>, and <literal>CREATEROLE</literal> can be thought of as
   special privileges, but they are never inherited as ordinary privileges
   on database objects are.  You must actually <command>SET ROLE</command> to a
   specific role having one of these attributes in order to make use of
   the attribute.  Continuing the above example, we might choose to
   grant <literal>CREATEDB</literal> and <literal>CREATEROLE</literal> to the
   <literal>admin</literal> role.  Then a session connecting as role <literal>joe</literal>
   would not have these privileges immediately, only after doing
   <command>SET ROLE admin</command>.
  </para>

  <para>
  </para>

  <para>
   To destroy a group role, use <link
   linkend="sql-droprole"><command>DROP ROLE</command></link>:
<synopsis>
DROP ROLE <replaceable>name</replaceable>;
</synopsis>
   Any memberships in the group role are automatically revoked (but the
   member roles are not otherwise affected).
  </para>
 </sect1>

 <sect1 id="role-removal">
  <title>Dropping Roles</title>

  <para>
   Because roles can own database objects and can hold privileges
   to access other objects, dropping a role is often not just a matter of a
   quick <link linkend="sql-droprole"><command>DROP ROLE</command></link>.  Any objects owned by the role must
   first be dropped or reassigned to other owners; and any permissions
   granted to the role must be revoked.
  </para>

  <para>
   Ownership of objects can be transferred one at a time
   using <command>ALTER</command> commands, for example:
<programlisting>
ALTER TABLE bobs_table OWNER TO alice;
</programlisting>
   Alternatively, the <link linkend="sql-reassign-owned"><command>REASSIGN OWNED</command></link> command can be
   used to reassign ownership of all objects owned by the role-to-be-dropped
   to a single other role.  Because <command>REASSIGN OWNED</command> 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 <command>REASSIGN OWNED</command> will change the ownership of any
   shared-across-databases objects, that is databases or tablespaces, that
   are owned by the role-to-be-dropped.)
  </para>

  <para>
   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 <link linkend="sql-drop-owned"><command>DROP OWNED</command></link> 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, <command>DROP
   OWNED</command> 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.
  </para>

  <para>
   <command>DROP OWNED</command> also takes care of removing any privileges granted
   to the target role for objects that do not belong to it.
   Because <command>REASSIGN OWNED</command> does not touch such objects, it's
   typically necessary to run both <command>REASSIGN OWNED</command>
   and <command>DROP OWNED</command> (in that order!) to fully remove the
   dependencies of a role to be dropped.
  </para>

  <para>
   In short then, the most general recipe for removing a role that has been
   used to own objects is:
  </para>
<programlisting>