created with <literal>INHERIT FALSE, SET
   FALSE</literal>, the <literal>CREATEROLE</literal> user doesn't inherit the
   privileges of the created role, nor can it access the privileges of that
   role using <literal>SET ROLE</literal>. However, since any user who has
   <literal>ADMIN OPTION</literal> on a role can grant membership in that
   role to any other user, the <literal>CREATEROLE</literal> user can gain
   access to the created role by simply granting that role back to
   themselves with the <literal>INHERIT</literal> and/or <literal>SET</literal>
   options. Thus, the fact that privileges are not inherited by default nor
   is <literal>SET ROLE</literal> granted by default is a safeguard against
   accidents, not a security feature. Also note that, because this automatic
   grant is granted by the bootstrap superuser, it cannot be removed or changed by
   the <literal>CREATEROLE</literal> user; however, any superuser could
   revoke it, modify it, and/or issue additional such grants to other
   <literal>CREATEROLE</literal> users. Whichever <literal>CREATEROLE</literal>
   users have <literal>ADMIN OPTION</literal> on a role at any given time
   can administer it.
  </para>
 </sect1>

 <sect1 id="role-membership">
  <title>Role Membership</title>

  <indexterm zone="role-membership">
   <primary>role</primary><secondary>membership in</secondary>
  </indexterm>

  <para>
   It is frequently convenient to group users together to ease
   management of privileges: that way, privileges can be granted to, or
   revoked from, a group as a whole.  In <productname>PostgreSQL</productname>
   this is done by creating a role that represents the group, and then
   granting <firstterm>membership</firstterm> in the group role to individual user
   roles.
  </para>

  <para>
   To set up a group role, first create the role:
<synopsis>
CREATE ROLE <replaceable>name</replaceable>;
</synopsis>
   Typically a role being used as a group would not have the <literal>LOGIN</literal>
   attribute, though you can set it if you wish.
  </para>

  <para>
   Once the group role exists, you can add and remove members using the
   <link linkend="sql-grant"><command>GRANT</command></link> and
   <link linkend="sql-revoke"><command>REVOKE</command></link> commands:
<synopsis>
GRANT <replaceable>group_role</replaceable> TO <replaceable>role1</replaceable>, ... ;
REVOKE <replaceable>group_role</replaceable> FROM <replaceable>role1</replaceable>, ... ;
</synopsis>
   You can grant membership to other group roles, too (since there isn't
   really any distinction between group roles and non-group roles).  The
   database will not let you set up circular membership loops.  Also,
   it is not permitted to grant membership in a role to
   <literal>PUBLIC</literal>.
  </para>

  <para>
   The members of a group role can use the privileges of the role in two
   ways.  First, member roles that have been granted membership with the
   <literal>SET</literal> option can do
   <link 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