<literal>TRUE</literal> or <literal>FALSE</literal>. The keyword
   <literal>OPTION</literal> is accepted as a synonym for
   <literal>TRUE</literal>, so that <literal>WITH ADMIN OPTION</literal>
   is a synonym for <literal>WITH ADMIN TRUE</literal>.  When altering
   an existing membership the omission of an option results in the current
   value being retained.
  </para>

  <para>
   The <literal>ADMIN</literal> option allows the member to
   in turn grant membership in the role to others, and revoke membership
   in the role as well.  Without the admin option, ordinary users cannot
   do that.  A role is not considered to hold <literal>WITH ADMIN
   OPTION</literal> on itself.  Database superusers can grant or revoke
   membership in any role to anyone. This option defaults to
   <literal>FALSE</literal>.
  </para>

  <para>
   The <literal>INHERIT</literal> option controls the inheritance status
   of the new membership;  see <xref linkend="role-membership"/> for
   details on inheritance.  If it is set to <literal>TRUE</literal>,
   it causes the new member to inherit from the granted role. If
   set to <literal>FALSE</literal>, the new member does not inherit.
   If unspecified when creating a new role membership, this defaults to the
   inheritance attribute of the new member.
  </para>

  <para>
   The <literal>SET</literal> option, if it is set to
   <literal>TRUE</literal>, allows the member to change to the granted
   role using the
   <link linkend="sql-set-role"><command>SET ROLE</command></link>
   command. If a role is an indirect member of another role, it can use
   <literal>SET ROLE</literal> to change to that role only if there is a
   chain of grants each of which has <literal>SET TRUE</literal>.
   This option defaults to <literal>TRUE</literal>.
  </para>

  <para>
   To create an object owned by another role or give ownership of an existing
   object to another role, you must have the ability to <literal>SET
   ROLE</literal> to that role; otherwise, commands such as <literal>ALTER
   ... OWNER TO</literal> or <literal>CREATE DATABASE ... OWNER</literal>
   will fail.  However, a user who inherits the privileges of a role but does
   not have the ability to <literal>SET ROLE</literal> to that role may be
   able to obtain full access to the role by manipulating existing objects
   owned by that role (e.g. they could redefine an existing function to act
   as a Trojan horse).  Therefore, if a role's privileges are to be inherited
   but should not be accessible via <literal>SET ROLE</literal>, it should not
   own any SQL objects.
  </para>

  <para>
   If <literal>GRANTED BY</literal> is specified, the grant is recorded as
   having been done by the specified role. A user can only attribute a grant
   to another role if they possess the privileges of that role. The role
   recorded as the grantor must have <literal>ADMIN OPTION</literal> on the
   target role, unless it is the bootstrap superuser. When a grant is recorded
   as having a grantor other than the bootstrap superuser, it depends on the
   grantor continuing to possess <literal>ADMIN OPTION</literal> on the role;
   so, if <literal>ADMIN OPTION</literal> is revoked, dependent grants must
   be revoked as well.
  </para>

  <para>
   Unlike the case with privileges, membership in a role cannot be granted
   to <literal>PUBLIC</literal>.  Note also that this form of the command
   does not allow the noise word <literal>GROUP</literal>
   in <replaceable class="parameter">role_specification</replaceable>.
  </para>
 </refsect2>
 </refsect1>


 <refsect1 id="sql-grant-notes">
  <title>Notes</title>

   <para>
    The <link linkend="sql-revoke"><command>REVOKE</command></link> command is used
    to revoke access privileges.
   </para>

   <para>
    Since <productname>PostgreSQL</productname> 8.1, the concepts of users and
    groups have been unified into a single kind of entity called a role.
    It is therefore no longer necessary to use the