<literal>READ_WRITE</literal> }</term>
    <listitem>
     <para>
      This option is like <literal>FINALFUNC_MODIFY</literal>, but it describes
      the behavior of the moving-aggregate final function.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">minitial_condition</replaceable></term>
    <listitem>
     <para>
      The initial setting for the state value, when using moving-aggregate
      mode.  This works the same as <replaceable>initial_condition</replaceable>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">sort_operator</replaceable></term>
    <listitem>
     <para>
      The associated sort operator for a <function>MIN</function>- or
      <function>MAX</function>-like aggregate.
      This is just an operator name (possibly schema-qualified).
      The operator is assumed to have the same input data types as
      the aggregate (which must be a single-argument normal aggregate).
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>PARALLEL =</literal> { <literal>SAFE</literal> | <literal>RESTRICTED</literal> | <literal>UNSAFE</literal> }</term>
    <listitem>
     <para>
      The meanings of <literal>PARALLEL SAFE</literal>, <literal>PARALLEL
      RESTRICTED</literal>, and <literal>PARALLEL UNSAFE</literal> are the same as
      in <link linkend="sql-createfunction"><command>CREATE FUNCTION</command></link>.  An aggregate will not be
      considered for parallelization if it is marked <literal>PARALLEL
      UNSAFE</literal> (which is the default!) or <literal>PARALLEL RESTRICTED</literal>.
      Note that the parallel-safety markings of the aggregate's support
      functions are not consulted by the planner, only the marking of the
      aggregate itself.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>HYPOTHETICAL</literal></term>
    <listitem>
     <para>
      For ordered-set aggregates only, this flag specifies that the aggregate
      arguments are to be processed according to the requirements for
      hypothetical-set aggregates: that is, the last few direct arguments must
      match the data types of the aggregated (<literal>WITHIN GROUP</literal>)
      arguments.  The <literal>HYPOTHETICAL</literal> flag has no effect on
      run-time behavior, only on parse-time resolution of the data types and
      collations of the aggregate's arguments.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   The parameters of <command>CREATE AGGREGATE</command> can be
   written in any order, not just the order illustrated above.
  </para>
 </refsect1>

 <refsect1 id="sql-createaggregate-notes" xreflabel="Notes">
  <title>Notes</title>

   <para>
    In parameters that specify support function names, you can write
    a schema name if needed, for example <literal>SFUNC = public.sum</literal>.
    Do not write argument types there, however &mdash; the argument types
    of the support functions are determined from other parameters.
   </para>

   <para>
    Ordinarily, PostgreSQL functions are expected to be true functions that
    do not modify their input values.  However, an aggregate transition
    function, <emphasis>when used in the context of an aggregate</emphasis>,
    is allowed to cheat and modify its transition-state argument in place.
    This can provide substantial performance benefits compared to making
    a fresh copy of the transition state each time.
   </para>

   <para>
    Likewise, while an aggregate final function is normally expected not to
    modify its input values, sometimes it is impractical to avoid modifying
    the transition-state argument.  Such behavior must be declared using
    the <literal>FINALFUNC_MODIFY</literal> parameter.
    The <literal>READ_WRITE</literal>
    value indicates that the final function modifies the transition state in
    unspecified ways.