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-grant-examples">
  <title>Examples</title>

  <para>
   Grant insert privilege to all users on table <literal>films</literal>:

<programlisting>
GRANT INSERT ON films TO PUBLIC;
</programlisting>
  </para>

  <para>
   Grant all available privileges to user <literal>manuel</literal> on view
   <literal>kinds</literal>:

<programlisting>
GRANT ALL PRIVILEGES ON kinds TO manuel;
</programlisting>

   Note that while the above will indeed grant all privileges if executed by a
   superuser or the owner of <literal>kinds</literal>, when executed by someone
   else it will only grant those permissions for which the someone else has
   grant options.
  </para>

  <para>
   Grant membership in role <literal>admins</literal> to user <literal>joe</literal>:

<programlisting>
GRANT admins TO joe;
</programlisting></para>
 </refsect1>

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

   <para>
    According to the SQL standard, the <literal>PRIVILEGES</literal>
    key word in <literal>ALL PRIVILEGES</literal> is required.  The
    SQL standard does not support setting the privileges on more than
    one object per command.
   </para>

   <para>
    <productname>PostgreSQL</productname> allows an object owner to revoke their
    own ordinary privileges: for example, a table owner can make the table
    read-only to themselves by revoking their own <literal>INSERT</literal>,
    <literal>UPDATE</literal>, <literal>DELETE</literal>, and <literal>TRUNCATE</literal>
    privileges.  This is not possible according to the SQL standard.  The
    reason is that <productname>PostgreSQL</productname> treats the owner's
    privileges as having been granted by the owner to themselves; therefore they
    can revoke them too.  In the SQL standard, the owner's privileges are
    granted by an assumed entity <quote>_SYSTEM</quote>.  Not being
    <quote>_SYSTEM</quote>, the owner cannot revoke these rights.
   </para>

   <para>
    According to the SQL standard, grant options can be granted to
    <literal>PUBLIC</literal>; PostgreSQL only supports granting grant options
    to roles.
   </para>

   <para>
    The SQL standard allows the <literal>GRANTED BY</literal> option to
    specify only <literal>CURRENT_USER</literal> or
    <literal>CURRENT_ROLE</literal>.  The other variants are PostgreSQL
    extensions.
   </para>

   <para>
    The SQL standard provides for a <literal>USAGE</literal> privilege
    on other kinds of objects: character sets, collations,
    translations.
   </para>

   <para>
    In the SQL standard, sequences only have a <literal>USAGE</literal>
    privilege, which controls the use of the <literal>NEXT VALUE FOR</literal>
    expression, which is equivalent to the
    function <function>nextval</function> in PostgreSQL.  The sequence
    privileges <literal>SELECT</literal> and <literal>UPDATE</literal> are
    PostgreSQL extensions.  The application of the
    sequence <literal>USAGE</literal> privilege to
    the <literal>currval</literal> function is also a PostgreSQL extension (as
    is the function itself).
   </para>

   <para>
    Privileges on databases, tablespaces, schemas, languages, and
    configuration parameters are
    <productname>PostgreSQL</productname> extensions.
   </para>
 </refsect1>


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

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

</refentry>