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 keyword <literal>GROUP</literal>
    to identify whether a grantee is a user or a group.  <literal>GROUP</literal>
    is still allowed in the command, but it is a noise word.
   </para>

   <para>
    A user may perform <command>SELECT</command>, <command>INSERT</command>, etc. on a
    column if they hold that privilege for either the specific column or
    its whole table.  Granting the privilege at the table level and then
    revoking it for one column will not do what one might wish: the
    table-level grant is unaffected by a column-level operation.
   </para>

   <para>
    When a non-owner of an object attempts to <command>GRANT</command> privileges
    on the object, the command will fail outright if the user has no
    privileges whatsoever on the object.  As long as some privilege is
    available, the command will proceed, but it will grant only those
    privileges for which the user has grant options.  The <command>GRANT ALL
    PRIVILEGES</command> forms will issue a warning message if no grant options are
    held, while the other forms will issue a warning if grant options for
    any of the privileges specifically named in the command are not held.
    (In principle these statements apply to the object owner as well, but
    since the owner is always treated as holding all grant options, the
    cases can never occur.)
   </para>

   <para>
    It should be noted that database superusers can access
    all objects regardless of object privilege settings.  This
    is comparable to the rights of <literal>root</literal> in a Unix system.
    As with <literal>root</literal>, it's unwise to operate as a superuser
    except when absolutely necessary.
   </para>

   <para>
    If a superuser chooses to issue a <command>GRANT</command> or <command>REVOKE</command>
    command, the command is performed as though it were issued by the
    owner of the affected object.  In particular, privileges granted via
    such a command will appear to have been granted by the object owner.
    (For role membership, the membership appears to have been granted
    by the bootstrap superuser.)
   </para>

   <para>
    <command>GRANT</command> and <command>REVOKE</command> can also be done by a role
    that is not the owner of the affected object, but is a member of the role
    that owns the object, or is a member of a role that holds privileges
    <literal>WITH GRANT OPTION</literal> on the object.  In this case the
    privileges will be recorded as having been granted by the role that
    actually owns the object or holds the privileges
    <literal>WITH GRANT OPTION</literal>.  For example, if table
    <literal>t1</literal> is owned by role <literal>g1</literal>, of which role
    <literal>u1</literal> is a member, then <literal>u1</literal> can grant privileges
    on <literal>t1</literal> to <literal>u2</literal>, but those privileges will appear
    to have been granted directly by <literal>g1</literal>.  Any other member
    of role