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>
    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.  (Since roles do not have owners, in the
    case of a <command>GRANT</command> of role membership, the command is
    performed as though it were issued by the bootstrap superuser.)
    Since all privileges ultimately come
    from the object owner (possibly indirectly via chains of grant options),
    it is possible for a superuser to revoke all privileges, but this might
    require use of <literal>CASCADE</literal> as stated above.
   </para>

   <para>
    <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
    command is performed as though it were issued by the containing 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 revoke privileges
    on <literal>t1</literal> that are recorded as being granted by <literal>g1</literal>.
    This would include grants made by <literal>u1</literal> as well as by other
    members of role <literal>g1</literal>.
   </para>

   <para>
    If the role executing <command>REVOKE</command> holds privileges
    indirectly via more than one role membership path, it is unspecified
    which containing role will be used to perform the command.  In such cases
    it is best practice to use <command>SET ROLE</command> to become the specific
    role you want to do the <command>REVOKE</command> as.  Failure to do so might
    lead to revoking privileges other than the ones you intended, or not
    revoking anything at all.
   </para>

   <para>
    See <xref linkend="ddl-priv"/> for more information about specific
    privilege types, as well as how to inspect objects' privileges.
   </para>
 </refsect1>

 <refsect1 id="sql-revoke-examples">
  <title>Examples</title>

  <para>
   Revoke insert privilege for the public on table
   <literal>films</literal>:

<programlisting>
REVOKE INSERT ON films FROM PUBLIC;
</programlisting>
  </para>

  <para>
   Revoke all privileges from user <literal>manuel</literal> on view
   <literal>kinds</literal>:

<programlisting>
REVOKE ALL PRIVILEGES ON kinds FROM manuel;
</programlisting>

   Note that this actually means <quote>revoke all privileges that I
   granted</quote>.
  </para>

  <para>
   Revoke membership in role <literal>admins</literal> from user <literal>joe</literal>:

<programlisting>
REVOKE admins FROM joe;
</programlisting></para>
 </refsect1>

 <refsect1 id="sql-revoke-compatibility">
  <title>Compatibility</title>

   <para>
    The compatibility notes of the <link linkend="sql-grant"><command>GRANT</command></link> command
    apply analogously to <command>REVOKE</command>.
    The keyword <literal>RESTRICT</literal> or <literal>CASCADE</literal>
    is required according to the standard, but <productname>PostgreSQL</productname>
    assumes <literal>RESTRICT</literal> by default.
   </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-grant"/></member>
   <member><xref linkend="sql-alterdefaultprivileges"/></member>
  </simplelist>
 </refsect1>

</refentry>