CURRENT_ROLE
  | CURRENT_USER
  | SESSION_USER
</synopsis>
 </refsynopsisdiv>

 <refsect1 id="sql-grant-description">
  <title>Description</title>

  <para>
   The <command>GRANT</command> command has two basic variants: one
   that grants privileges on a database object (table, column, view,
   foreign table, sequence, database, foreign-data wrapper, foreign server,
   function, procedure, procedural language, large object, configuration
   parameter, schema, tablespace, or type), and one that grants
   membership in a role.  These variants are similar in many ways, but
   they are different enough to be described separately.
  </para>

 <refsect2 id="sql-grant-description-objects">
  <title>GRANT on Database Objects</title>

  <para>
   This variant of the <command>GRANT</command> command gives specific
   privileges on a database object to
   one or more roles.  These privileges are added
   to those already granted, if any.
  </para>

  <para>
   The key word <literal>PUBLIC</literal> indicates that the
   privileges are to be granted to all roles, including those that might
   be created later.  <literal>PUBLIC</literal> can be thought of as an
   implicitly defined group that always includes all roles.
   Any particular role will have the sum
   of privileges granted directly to it, privileges granted to any role it
   is presently a member of, and privileges granted to
   <literal>PUBLIC</literal>.
  </para>

  <para>
   If <literal>WITH GRANT OPTION</literal> is specified, the recipient
   of the privilege can in turn grant it to others.  Without a grant
   option, the recipient cannot do that.  Grant options cannot be granted
   to <literal>PUBLIC</literal>.
  </para>

  <para>
   If <literal>GRANTED BY</literal> is specified, the specified grantor must
   be the current user.  This clause is currently present in this form only
   for SQL compatibility.
  </para>

  <para>
   There is no need to grant privileges to the owner of an object
   (usually the user that created it),
   as the owner has all privileges by default.  (The owner could,
   however, choose to revoke some of their own privileges for safety.)
  </para>

  <para>
   The right to drop an object, or to alter its definition in any way, is
   not treated as a grantable privilege; it is inherent in the owner,
   and cannot be granted or revoked.  (However, a similar effect can be
   obtained by granting or revoking membership in the role that owns
   the object; see below.)  The owner implicitly has all grant
   options for the object, too.
  </para>

  <para>
   The possible privileges are:

   <variablelist>
    <varlistentry>
     <term><literal>SELECT</literal></term>
     <term><literal>INSERT</literal></term>
     <term><literal>UPDATE</literal></term>
     <term><literal>DELETE</literal></term>
     <term><literal>TRUNCATE</literal></term>
     <term><literal>REFERENCES</literal></term>
     <term><literal>TRIGGER</literal></term>
     <term><literal>CREATE</literal></term>
     <term><literal>CONNECT</literal></term>
     <term><literal>TEMPORARY</literal></term>
     <term><literal>EXECUTE</literal></term>
     <term><literal>USAGE</literal></term>
     <term><literal>SET</literal></term>
     <term><literal>ALTER SYSTEM</literal></term>
     <term><literal>MAINTAIN</literal></term>
     <listitem>
      <para>
       Specific types of privileges, as defined in <xref linkend="ddl-priv"/>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>TEMP</literal></term>
     <listitem>
      <para>
       Alternative spelling for <literal>TEMPORARY</literal>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>ALL PRIVILEGES</literal></term>
     <listitem>
      <para>
       Grant all of the privileges available for the object's type.
       The <literal>PRIVILEGES</literal> key word is optional in
       <productname>PostgreSQL</productname>, though it is required by
       strict