types there, however — 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.  This value prevents use of the aggregate as a window
    function, and it also prevents merging of transition states for aggregate
    calls that share the same input values and transition functions.
    The <literal>SHAREABLE</literal> value indicates that the transition function
    cannot be applied after the final function, but multiple final-function
    calls can be performed on the ending transition state value.  This value
    prevents use of the aggregate as a window function, but it allows merging
    of transition states.  (That is, the optimization of interest here is not
    applying the same final function repeatedly, but applying different final
    functions to the same ending transition state value.  This is allowed as
    long as none of the final functions are marked <literal>READ_WRITE</literal>.)
   </para>

   <para>
    If an aggregate supports moving-aggregate mode, it will improve
    calculation efficiency when the aggregate is used as a window function
    for a window with moving frame start (that is, a frame start mode other
    than <literal>UNBOUNDED PRECEDING</literal>).  Conceptually, the forward
    transition function adds input values to the aggregate's state when
    they enter the window frame from the bottom, and the inverse transition
    function removes them again when they leave the frame at the top.  So,
    when values are removed, they are always removed in the same order they
    were added.  Whenever the inverse transition function is invoked, it will
    thus receive the earliest added but not yet removed argument value(s).
    The inverse transition function can assume that at least one row will
    remain in the current state after it removes the oldest row.  (When this
    would not be the case, the window function mechanism simply starts a
    fresh aggregation, rather than using the inverse transition function.)
   </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