linkend="sql-set-role"><command>SET ROLE</command></link> to
   temporarily <quote>become</quote> the group role.  In this state, the
   database session has access to the privileges of the group role rather
   than the original login role, and any database objects created are
   considered owned by the group role, not the login role.  Second, member
   roles that have been granted membership with the
   <literal>INHERIT</literal> option automatically have use of the
   privileges of those directly or indirectly a member of, though the
   chain stops at memberships lacking the inherit option.  As an example,
   suppose we have done:
<programlisting>
CREATE ROLE joe LOGIN;
CREATE ROLE admin;
CREATE ROLE wheel;
CREATE ROLE island;
GRANT admin TO joe WITH INHERIT TRUE;
GRANT wheel TO admin WITH INHERIT FALSE;
GRANT island TO joe WITH INHERIT TRUE, SET FALSE;
</programlisting>
   Immediately after connecting as role <literal>joe</literal>, a database
   session will have use of privileges granted directly to <literal>joe</literal>
   plus any privileges granted to <literal>admin</literal> and
   <literal>island</literal>, because <literal>joe</literal>
   <quote>inherits</quote> those privileges.  However, privileges
   granted to <literal>wheel</literal> are not available, because even though
   <literal>joe</literal> is indirectly a member of <literal>wheel</literal>, the
   membership is via <literal>admin</literal> which was granted using
   <literal>WITH INHERIT FALSE</literal>. After:
<programlisting>
SET ROLE admin;
</programlisting>
   the session would have use of only those privileges granted to
   <literal>admin</literal>, and not those granted to <literal>joe</literal> or
   <literal>island</literal>.  After:
<programlisting>
SET ROLE wheel;
</programlisting>
   the session would have use of only those privileges granted to
   <literal>wheel</literal>, and not those granted to either <literal>joe</literal>
   or <literal>admin</literal>.  The original privilege state can be restored
   with any of:
<programlisting>
SET ROLE joe;
SET ROLE NONE;
RESET ROLE;
</programlisting>
  </para>

  <note>
   <para>
    The <command>SET ROLE</command> command always allows selecting any role
    that the original login role is directly or indirectly a member of,
    provided that there is a chain of membership grants each of which has
    <literal>SET TRUE</literal> (which is the default).
    Thus, in the above example, it is not necessary to become
    <literal>admin</literal> before becoming <literal>wheel</literal>.
    On the other hand, it is not possible to become <literal>island</literal>
    at all; <literal>joe</literal> can only access those privileges via
    inheritance.
   </para>
  </note>

  <note>
   <para>
    In the SQL standard, there is a clear distinction between users and roles,
    and users do not automatically inherit privileges while roles do.  This
    behavior can be obtained in <productname>PostgreSQL</productname> by 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>