linkend="sql-revoke"><command>REVOKE</command></link> for that.)
   Attributes not mentioned in the command retain their previous settings.
   Database superusers can change any of these settings for any role, except
   for changing the <literal>SUPERUSER</literal> property for the
   <glossterm linkend="glossary-bootstrap-superuser">bootstrap superuser</glossterm>.
   Non-superuser roles having <literal>CREATEROLE</literal> privilege can
   change most of these properties, but only for non-superuser and
   non-replication roles for which they have been granted
   <literal>ADMIN OPTION</literal>. Non-superusers cannot change the
   <literal>SUPERUSER</literal> property and can change the
   <literal>CREATEDB</literal>, <literal>REPLICATION</literal>, and
   <literal>BYPASSRLS</literal> properties only if they possess the
   corresponding property themselves.
   Ordinary roles can only change their own password.
  </para>

  <para>
   The second variant changes the name of the role.
   Database superusers can rename any role.
   Roles having <literal>CREATEROLE</literal> privilege can rename non-superuser
   roles for which they have been granted <literal>ADMIN OPTION</literal>.
   The current session user cannot be renamed.
   (Connect as a different user if you need to do that.)
   Because <literal>MD5</literal>-encrypted passwords use the role name as
   cryptographic salt, renaming a role clears its password if the
   password is <literal>MD5</literal>-encrypted.
  </para>

  <para>
   The remaining variants change a role's session default for a configuration
   variable, either for all databases or, when the <literal>IN
   DATABASE</literal> clause is specified, only for sessions in the named
   database.  If <literal>ALL</literal> is specified instead of a role name,
   this changes the setting for all roles.  Using <literal>ALL</literal>
   with <literal>IN DATABASE</literal> is effectively the same as using the
   command <literal>ALTER DATABASE ... SET ...</literal>.
  </para>

  <para>
   Whenever the role subsequently
   starts a new session, the specified value becomes the session
   default, overriding whatever setting is present in
   <filename>postgresql.conf</filename> or has been received from the <command>postgres</command>
   command line. This only happens at login time; executing
   <link linkend="sql-set-role"><command>SET ROLE</command></link> or
   <link linkend="sql-set-session-authorization"><command>SET SESSION AUTHORIZATION</command></link> does not cause new
   configuration values to be set.
   Settings set for all databases are overridden by database-specific settings
   attached to a role.  Settings for specific databases or specific roles override
   settings for all roles.
  </para>

  <para>
   Superusers can change anyone's session defaults. Roles having
   <literal>CREATEROLE</literal> privilege can change defaults for non-superuser
   roles for which they have been granted <literal>ADMIN OPTION</literal>.
   Ordinary roles can only set defaults for themselves.
   Certain configuration variables cannot be set this way, or can only be
   set if a superuser issues the command.  Only superusers can change a setting
   for all roles in all databases.
  </para>
 </refsect1>

 <refsect1 id="sql-alterrole-params">
  <title>Parameters</title>

    <variablelist>
     <varlistentry id="sql-alterrole-params-name">
      <term><replaceable class="parameter">name</replaceable></term>
      <listitem>
       <para>
        The name of the role whose attributes are to be altered.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="sql-alterrole-params-current-role">
      <term><literal>CURRENT_ROLE</literal></term>
      <term><literal>CURRENT_USER</literal></term>
      <listitem>
       <para>
        Alter the current user instead of an explicitly identified role.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="sql-alterrole-params-session-user">