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>
REASSIGN OWNED BY doomed_role TO successor_role;
DROP OWNED BY doomed_role;
-- repeat the above commands in each database of the cluster
DROP ROLE doomed_role;
</programlisting>

  <para>
   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.
  </para>

  <para>
   If <command>DROP ROLE</command> is attempted while dependent objects still
   remain, it will issue messages identifying which objects need to be
   reassigned or dropped.
  </para>
 </sect1>

 <sect1 id="predefined-roles">
  <title>Predefined Roles</title>

  <indexterm zone="predefined-roles">
   <primary>role</primary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> provides a set of predefined roles
   that provide access to certain, commonly needed, privileged capabilities
   and information.  Administrators (including roles that have the
   <literal>CREATEROLE</literal> privilege) can <command>GRANT</command> these
   roles to users and/or other roles in their environment, providing those
   users with access to the specified capabilities and information.  For
   example:

<programlisting>
GRANT pg_signal_backend TO admin_user;
</programlisting>
  </para>

  <warning>
   <para>
    Care should be taken when granting these roles to ensure they are only used
    where needed and with the understanding that these roles grant access to
    privileged information.
   </para>
  </warning>

  <para>
   The predefined roles are described below.
   Note that the specific permissions for each of the roles may change in
   the future as additional capabilities are added.  Administrators
   should monitor the release notes for changes.

   <variablelist>
    <varlistentry id="predefined-role-pg-checkpoint" xreflabel="pg_checkpoint">
     <term><varname>pg_checkpoint</varname></term>
     <listitem>
      <para>
       <literal>pg_checkpoint</literal> allows executing the
       <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link> command.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-create-subscription" xreflabel="pg_create_subscription">
     <term><varname>pg_create_subscription</varname></term>
     <listitem>
      <para>
       <literal>pg_create_subscription</literal> allows users with
       <literal>CREATE</literal> permission on the database to issue
       <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-database-owner" xreflabel="pg_database_owner">
     <term><varname>pg_database_owner</varname></term>
     <listitem>
      <para>
       <literal>pg_database_owner</literal> always has exactly one implicit
       member: the current database owner.  It cannot be granted membership in
       any role, and no role can be granted membership