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 persistent changes to
      settings.  They should
      be labeled parallel restricted if they access temporary tables,
      client connection state, cursors, prepared statements, or miscellaneous
      backend-local state which the system cannot synchronize in parallel mode
      (e.g.,  <literal>setseed</literal> cannot be executed other than by the group
      leader because a change made by another process would not be reflected
      in the leader).  In general, if a function is labeled as being safe when
      it is restricted or unsafe, or if it is labeled as being restricted when
      it is in fact unsafe, it may throw errors or produce wrong answers
      when used in a parallel query.  C-language functions could in theory
      exhibit totally undefined behavior if mislabeled, since there is no way
      for the system to protect itself against arbitrary C code, but in most
      likely cases the result will be no worse than for any other function.
      If in doubt, functions should be labeled as <literal>UNSAFE</literal>, which is
      the default.
     </para>
    </listitem>
   </varlistentry>

    <varlistentry>
     <term><literal>COST</literal> <replaceable class="parameter">execution_cost</replaceable></term>

     <listitem>
      <para>
       A positive number giving the estimated execution cost for the function,
       in units of <xref linkend="guc-cpu-operator-cost"/>.  If the function
       returns a set, this is the cost per returned row.  If the cost is
       not specified, 1 unit is assumed for C-language and internal functions,
       and 100 units for functions in all other languages.  Larger values
       cause the planner to try to avoid evaluating the function more often
       than necessary.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>ROWS</literal> <replaceable class="parameter">result_rows</replaceable></term>

     <listitem>
      <para>
       A positive number giving the estimated number of rows that the planner
       should expect the function to return.  This is only allowed when the
       function is declared to return a set.  The default assumption is
       1000 rows.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>SUPPORT</literal> <replaceable class="parameter">support_function</replaceable></term>

     <listitem>
      <para>
       The name (optionally schema-qualified) of a <firstterm>planner support
       function</firstterm> to use for this function.  See
       <xref linkend="xfunc-optimization"/> for details.
       You must be superuser to use this option.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>configuration_parameter</replaceable></term>
     <term><replaceable>value</replaceable></term>
     <listitem>
      <para>
       The <literal>SET</literal> clause causes the specified configuration
       parameter to be set to the specified value