work either.
  </para>

  <para>
   A serialization function must take a single argument of
   type <type>internal</type> and return a result of type <type>bytea</type>, which
   represents the state value packaged up into a flat blob of bytes.
   Conversely, a deserialization function reverses that conversion.  It must
   take two arguments of types <type>bytea</type> and <type>internal</type>, and
   return a result of type <type>internal</type>.  (The second argument is unused
   and is always zero, but it is required for type-safety reasons.)  The
   result of the deserialization function should simply be allocated in the
   current memory context, as unlike the combine function's result, it is not
   long-lived.
  </para>

  <para>
   Worth noting also is that for an aggregate to be executed in parallel,
   the aggregate itself must be marked <literal>PARALLEL SAFE</literal>.  The
   parallel-safety markings on its support functions are not consulted.
  </para>

 </sect2>

 <sect2 id="xaggr-support-functions">
  <title>Support Functions for Aggregates</title>

  <indexterm>
   <primary>aggregate function</primary>
   <secondary>support functions for</secondary>
  </indexterm>

  <para>
   A function written in C can detect that it is being called as an
   aggregate support function by calling
   <function>AggCheckCallContext</function>, for example:
<programlisting>
if (AggCheckCallContext(fcinfo, NULL))
</programlisting>
   One reason for checking this is that when it is true, the first input
   must be a temporary state value and can therefore safely be modified
   in-place rather than allocating a new copy.
   See <function>int8inc()</function> for an example.
   (While aggregate transition functions are always allowed to modify
   the transition value in-place, aggregate final functions are generally
   discouraged from doing so; if they do so, the behavior must be declared
   when creating the aggregate.  See <xref linkend="sql-createaggregate"/>
   for more detail.)
  </para>

  <para>
   The second argument of <function>AggCheckCallContext</function> can be used to
   retrieve the memory context in which aggregate state values are being kept.
   This is useful for transition functions that wish to use <quote>expanded</quote>
   objects (see <xref linkend="xtypes-toast"/>) as their state values.
   On first call, the transition function should return an expanded object
   whose memory context is a child of the aggregate state context, and then
   keep returning the same expanded object on subsequent calls.  See
   <function>array_append()</function> for an example.  (<function>array_append()</function>
   is not the transition function of any built-in aggregate, but it is written
   to behave efficiently when used as transition function of a custom
   aggregate.)
  </para>

  <para>
   Another support routine available to aggregate functions written in C
   is <function>AggGetAggref</function>, which returns the <literal>Aggref</literal>
   parse node that defines the aggregate call.  This is mainly useful
   for ordered-set aggregates, which can inspect the substructure of
   the <literal>Aggref</literal> node to find out what sort ordering they are
   supposed to implement.  Examples can be found
   in <filename>orderedsetaggs.c</filename> in the <productname>PostgreSQL</productname>
   source code.
  </para>

 </sect2>

 </sect1>