function is not strict, then it will be called
   unconditionally at each input row, and must deal with null inputs
   and null state values for itself.  This allows the aggregate
   author to have full control over the aggregate's handling of null values.
  </para>

  <para>
   If the final function is declared <quote>strict</quote>, then it will not
   be called when the ending state value is null; instead a null result
   will be returned automatically.  (Of course this is just the normal
   behavior of strict functions.)  In any case the final function has
   the option of returning a null value.  For example, the final function for
   <function>avg</function> returns null when it sees there were zero
   input rows.
  </para>

  <para>
   Sometimes it is useful to declare the final function as taking not just
   the state value, but extra parameters corresponding to the aggregate's
   input values.  The main reason for doing this is if the final function
   is polymorphic and the state value's data type would be inadequate to
   pin down the result type.  These extra parameters are always passed as
   NULL (and so the final function must not be strict when
   the <literal>FINALFUNC_EXTRA</literal> option is used), but nonetheless they
   are valid parameters.  The final function could for example make use
   of <function>get_fn_expr_argtype</function> to identify the actual argument type
   in the current call.
  </para>

  <para>
   An aggregate can optionally support <firstterm>moving-aggregate mode</firstterm>,
   as described in <xref linkend="xaggr-moving-aggregates"/>.  This requires
   specifying the <literal>MSFUNC</literal>, <literal>MINVFUNC</literal>,
   and <literal>MSTYPE</literal> parameters, and optionally
   the <literal>MSSPACE</literal>, <literal>MFINALFUNC</literal>,
   <literal>MFINALFUNC_EXTRA</literal>, <literal>MFINALFUNC_MODIFY</literal>,
   and <literal>MINITCOND</literal> parameters.  Except for <literal>MINVFUNC</literal>,
   these parameters work like the corresponding simple-aggregate parameters
   without <literal>M</literal>; they define a separate implementation of the
   aggregate that includes an inverse transition function.
  </para>

  <para>
   The syntax with <literal>ORDER BY</literal> in the parameter list creates
   a special type of aggregate called an <firstterm>ordered-set
   aggregate</firstterm>; or if <literal>HYPOTHETICAL</literal> is specified, then
   a <firstterm>hypothetical-set aggregate</firstterm> is created.  These
   aggregates operate over groups of sorted values in order-dependent ways,
   so that specification of an input sort order is an essential part of a
   call.  Also, they can have <firstterm>direct</firstterm> arguments, which are
   arguments that are evaluated only once per aggregation rather than once
   per input row.  Hypothetical-set aggregates are a subclass of ordered-set
   aggregates in which some of the direct arguments are required to match,
   in number and data types, the aggregated argument columns.  This allows
   the values of those direct arguments to be added to the collection of
   aggregate-input rows as an additional <quote>hypothetical</quote> row.
  </para>

  <para>
   An aggregate can optionally support <firstterm>partial aggregation</firstterm>,
   as described in <xref linkend="xaggr-partial-aggregates"/>.
   This requires specifying the <literal>COMBINEFUNC</literal> parameter.
   If the <replaceable class="parameter">state_data_type</replaceable>
   is <type>internal</type>, it's usually also appropriate to provide the
   <literal>SERIALFUNC</literal> and <literal>DESERIALFUNC</literal> parameters so that
   parallel aggregation is possible.  Note that the aggregate must also be
   marked <literal>PARALLEL SAFE</literal> to enable parallel aggregation.
  </para>

  <para>
   Aggregates that behave like <function>MIN</function> or <function>MAX</function> can
   sometimes be optimized by looking into an index instead of scanning