<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 SQL.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   The <literal>FUNCTION</literal> syntax works for plain functions,
   aggregate functions, and window functions, but not for procedures;
   use <literal>PROCEDURE</literal> for those.
   Alternatively, use <literal>ROUTINE</literal> to refer to a function,
   aggregate function, window function, or procedure regardless of its
   precise type.
  </para>

  <para>
   There is also an option to grant privileges on all objects of the same
   type within one or more schemas.  This functionality is currently supported
   only for tables, sequences, functions, and procedures.  <literal>ALL
   TABLES</literal> also affects views and foreign tables, just like the
   specific-object <command>GRANT</command> command.  <literal>ALL
   FUNCTIONS</literal> also affects aggregate and window functions, but not
   procedures, again just like the specific-object <command>GRANT</command>
   command.  Use <literal>ALL ROUTINES</literal> to include procedures.
  </para>
 </refsect2>

 <refsect2 id="sql-grant-description-roles">
  <title>GRANT on Roles</title>

  <para>
   This variant of the <command>GRANT</command> command grants membership
   in a role to one or more other roles, and the modification of
   membership options <literal>SET</literal>, <literal>INHERIT</literal>,
   and <literal>ADMIN</literal>;  see <xref linkend="role-membership"/>
   for details.  Membership in a role is significant
   because it potentially allows access to the privileges granted to a role
   to each of its members, and potentially also the ability to make changes
   to the role itself. However, the actual permissions conferred depend on
   the options associated with the grant.  To modify that options of
   an existing membership, simply specify the membership with updated
   option values.
  </para>

  <para>
   Each of the options described below can be set to either
   <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