<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