which throws an error message
       for some argument values but not others, or which includes the argument
       values in any error message, is not leakproof.  This affects how the
       system executes queries against views created with the
       <literal>security_barrier</literal> option or tables with row level
       security enabled.  The system will enforce conditions from security
       policies and security barrier views before any user-supplied conditions
       from the query itself that contain non-leakproof functions, in order to
       prevent the inadvertent exposure of data.  Functions and operators
       marked as leakproof are assumed to be trustworthy, and may be executed
       before conditions from security policies and security barrier views.
       In addition, functions which do not take arguments or which are not
       passed any arguments from the security barrier view or table do not have
       to be marked as leakproof to be executed before security conditions.  See
       <xref linkend="sql-createview"/> and <xref linkend="rules-privileges"/>.
       This option can only be set by the superuser.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>CALLED ON NULL INPUT</literal></term>
     <term><literal>RETURNS NULL ON NULL INPUT</literal></term>
     <term><literal>STRICT</literal></term>

     <listitem>
      <para><literal>CALLED ON NULL INPUT</literal> (the default) indicates
       that the function will be called normally when some of its
       arguments are null.  It is then the function author's
       responsibility to check for null values if necessary and respond
       appropriately.
      </para>

      <para><literal>RETURNS NULL ON NULL INPUT</literal> or
       <literal>STRICT</literal> indicates that the function always
       returns null whenever any of its arguments are null.  If this
       parameter is specified, the function is not executed when there
       are null arguments; instead a null result is assumed
       automatically.
      </para>
     </listitem>
    </varlistentry>

   <varlistentry>
    <term><literal><optional>EXTERNAL</optional> SECURITY INVOKER</literal></term>
    <term><literal><optional>EXTERNAL</optional> SECURITY DEFINER</literal></term>

    <listitem>
     <para><literal>SECURITY INVOKER</literal> indicates that the function
      is to be executed with the privileges of the user that calls it.
      That is the default.  <literal>SECURITY DEFINER</literal>
      specifies that the function is to be executed with the
      privileges of the user that owns it. For information on how to
      write <literal>SECURITY DEFINER</literal> functions safely,
      <link linkend="sql-createfunction-security">see below</link>.
     </para>

     <para>
      The key word <literal>EXTERNAL</literal> is allowed for SQL
      conformance, but it is optional since, unlike in SQL, this feature
      applies to all functions not only external ones.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>PARALLEL</literal></term>

    <listitem>
     <para>
      <literal>PARALLEL UNSAFE</literal> indicates that the function
      can't be executed in parallel mode; the presence of such a
      function in an SQL statement forces a serial execution plan.  This is
      the default.  <literal>PARALLEL RESTRICTED</literal> indicates that
      the function can be executed in parallel mode, but only in the parallel
      group leader process.  <literal>PARALLEL SAFE</literal>
      indicates that the function is safe to run in parallel mode without
      restriction, including in parallel worker processes.
     </para>

     <para>
      Functions should be labeled parallel unsafe if they modify any database
      state, change the transaction state (other than by using a
      subtransaction for error recovery), access sequences (e.g., by
      calling <literal>currval</literal>) or make