<firstterm>moving-aggregate
   mode</firstterm>, which allows substantially faster execution of aggregate
   functions within windows with moving frame starting points.
   (See <xref linkend="tutorial-window"/>
   and <xref linkend="syntax-window-functions"/> for information about use of
   aggregate functions as window functions.)
   The basic idea is that in addition to a normal <quote>forward</quote>
   transition function, the aggregate provides an <firstterm>inverse
   transition function</firstterm>, which allows rows to be removed from the
   aggregate's running state value when they exit the window frame.
   For example a <function>sum</function> aggregate, which uses addition as the
   forward transition function, would use subtraction as the inverse
   transition function.  Without an inverse transition function, the window
   function mechanism must recalculate the aggregate from scratch each time
   the frame starting point moves, resulting in run time proportional to the
   number of input rows times the average frame length.  With an inverse
   transition function, the run time is only proportional to the number of
   input rows.
  </para>

  <para>
   The inverse transition function is passed the current state value and the
   aggregate input value(s) for the earliest row included in the current
   state.  It must reconstruct what the state value would have been if the
   given input row had never been aggregated, but only the rows following
   it.  This sometimes requires that the forward transition function keep
   more state than is needed for plain aggregation mode.  Therefore, the
   moving-aggregate mode uses a completely separate implementation from the
   plain mode: it has its own state data type, its own forward transition
   function, and its own final function if needed.  These can be the same as
   the plain mode's data type and functions, if there is no need for extra
   state.
  </para>

  <para>
   As an example, we could extend the <function>sum</function> aggregate given above
   to support moving-aggregate mode like this:

<programlisting>
CREATE AGGREGATE sum (complex)
(
    sfunc = complex_add,
    stype = complex,
    initcond = '(0,0)',
    msfunc = complex_add,
    minvfunc = complex_sub,
    mstype = complex,
    minitcond = '(0,0)'
);
</programlisting>

   The parameters whose names begin with <literal>m</literal> define the
   moving-aggregate implementation.  Except for the inverse transition
   function <literal>minvfunc</literal>, they correspond to the plain-aggregate
   parameters without <literal>m</literal>.
  </para>

  <para>
   The forward transition function for moving-aggregate mode is not allowed
   to return null as the new state value.  If the inverse transition
   function returns null, this is taken as an indication that the inverse
   function cannot reverse the state calculation for this particular input,
   and so the aggregate calculation will be redone from scratch for the
   current frame starting position.  This convention allows moving-aggregate
   mode to be used in situations where there are some infrequent cases that
   are impractical to reverse out of the running state value.  The inverse
   transition function can <quote>punt</quote> on these cases, and yet still come
   out ahead so long as it can work for most cases.  As an example, an
   aggregate working with floating-point numbers might choose to punt when
   a <literal>NaN</literal> (not a number) input has to be removed from the running
   state value.
  </para>

  <para>
   When writing moving-aggregate support functions, it is important to be
   sure that the inverse transition function can reconstruct the correct
   state value exactly.  Otherwise there might be user-visible differences
   in results depending on whether the moving-aggregate mode is used.
   An example of an aggregate for which adding an inverse transition
   function seems easy at first, yet where this requirement cannot be met