mirror of
https://github.com/postgres/postgres.git
synced 2025-05-28 05:21:27 +03:00
183 lines
6.3 KiB
Plaintext
183 lines
6.3 KiB
Plaintext
<!--
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/xaggr.sgml,v 1.22 2003/08/31 17:32:20 petere Exp $
|
|
-->
|
|
|
|
<sect1 id="xaggr">
|
|
<title>User-Defined Aggregates</title>
|
|
|
|
<indexterm zone="xaggr">
|
|
<primary>aggregate function</primary>
|
|
<secondary>user-defined</secondary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
Aggregate functions in <productname>PostgreSQL</productname>
|
|
are expressed as <firstterm>state values</firstterm>
|
|
and <firstterm>state transition functions</firstterm>.
|
|
That is, an aggregate can be
|
|
defined in terms of state that is modified whenever an
|
|
input item is processed. To define a new aggregate
|
|
function, one selects a data type for the state value,
|
|
an initial value for the state, and a state transition
|
|
function. The state transition function is just an
|
|
ordinary function that could also be used outside the
|
|
context of the aggregate. A <firstterm>final function</firstterm>
|
|
can also be specified, in case the desired result of the aggregate
|
|
is different from the data that needs to be kept in the running
|
|
state value.
|
|
</para>
|
|
|
|
<para>
|
|
Thus, in addition to the argument and result data types seen by a user
|
|
of the aggregate, there is an internal state-value data type that
|
|
may be different from both the argument and result types.
|
|
</para>
|
|
|
|
<para>
|
|
If we define an aggregate that does not use a final function,
|
|
we have an aggregate that computes a running function of
|
|
the column values from each row. <function>sum</> is an
|
|
example of this kind of aggregate. <function>sum</> starts at
|
|
zero and always adds the current row's value to
|
|
its running total. For example, if we want to make a <function>sum</>
|
|
aggregate to work on a data type for complex numbers,
|
|
we only need the addition function for that data type.
|
|
The aggregate definition would be:
|
|
|
|
<screen>
|
|
CREATE AGGREGATE complex_sum (
|
|
sfunc = complex_add,
|
|
basetype = complex,
|
|
stype = complex,
|
|
initcond = '(0,0)'
|
|
);
|
|
|
|
SELECT complex_sum(a) FROM test_complex;
|
|
|
|
complex_sum
|
|
-------------
|
|
(34,53.9)
|
|
</screen>
|
|
|
|
(In practice, we'd just name the aggregate <function>sum</function> and rely on
|
|
<productname>PostgreSQL</productname> to figure out which kind
|
|
of sum to apply to a column of type <type>complex</type>.)
|
|
</para>
|
|
|
|
<para>
|
|
The above definition of <function>sum</function> will return zero (the initial
|
|
state condition) if there are no nonnull input values.
|
|
Perhaps we want to return null in that case instead --- the SQL standard
|
|
expects <function>sum</function> to behave that way. We can do this simply by
|
|
omitting the <literal>initcond</literal> phrase, so that the initial state
|
|
condition is null. Ordinarily this would mean that the <literal>sfunc</literal>
|
|
would need to check for a null state-condition input, but for
|
|
<function>sum</function> and some other simple aggregates like
|
|
<function>max</> and <function>min</>,
|
|
it is sufficient to insert the first nonnull input value into
|
|
the state variable and then start applying the transition function
|
|
at the second nonnull input value. <productname>PostgreSQL</productname>
|
|
will do that automatically if the initial condition is null and
|
|
the transition function is marked <quote>strict</> (i.e., not to be called
|
|
for null inputs).
|
|
</para>
|
|
|
|
<para>
|
|
Another bit of default behavior for a <quote>strict</> transition function
|
|
is that the previous state value is retained unchanged whenever a
|
|
null input value is encountered. Thus, null values are ignored. If you
|
|
need some other behavior for null inputs, just do not define your transition
|
|
function as strict, and code it to test for null inputs and do
|
|
whatever is needed.
|
|
</para>
|
|
|
|
<para>
|
|
<function>avg</> (average) is a more complex example of an aggregate. It requires
|
|
two pieces of running state: the sum of the inputs and the count
|
|
of the number of inputs. The final result is obtained by dividing
|
|
these quantities. Average is typically implemented by using a
|
|
two-element array as the state value. For example,
|
|
the built-in implementation of <function>avg(float8)</function>
|
|
looks like:
|
|
|
|
<programlisting>
|
|
CREATE AGGREGATE avg (
|
|
sfunc = float8_accum,
|
|
basetype = float8,
|
|
stype = float8[],
|
|
finalfunc = float8_avg,
|
|
initcond = '{0,0}'
|
|
);
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
Aggregate functions may use polymorphic
|
|
state transition functions or final functions, so that the same functions
|
|
can be used to implement multiple aggregates.
|
|
See <xref linkend="extend-types-polymorphic">
|
|
for an explanation of polymorphic functions.
|
|
Going a step further, the aggregate function itself may be specified
|
|
with a polymorphic base type and state type, allowing a single
|
|
aggregate definition to serve for multiple input data types.
|
|
Here is an example of a polymorphic aggregate:
|
|
|
|
<programlisting>
|
|
CREATE AGGREGATE array_accum (
|
|
sfunc = array_append,
|
|
basetype = anyelement,
|
|
stype = anyarray,
|
|
initcond = '{}'
|
|
);
|
|
</programlisting>
|
|
|
|
Here, the actual state type for any aggregate call is the array type
|
|
having the actual input type as elements.
|
|
</para>
|
|
|
|
<para>
|
|
Here's the output using two different actual data types as arguments:
|
|
|
|
<programlisting>
|
|
SELECT attrelid::regclass, array_accum(attname)
|
|
FROM pg_attribute WHERE attnum > 0
|
|
AND attrelid = 'pg_user'::regclass GROUP BY attrelid;
|
|
attrelid | array_accum
|
|
----------+-----------------------------------------------------------------------------
|
|
pg_user | {usename,usesysid,usecreatedb,usesuper,usecatupd,passwd,valuntil,useconfig}
|
|
(1 row)
|
|
|
|
SELECT attrelid::regclass, array_accum(atttypid)
|
|
FROM pg_attribute WHERE attnum > 0
|
|
AND attrelid = 'pg_user'::regclass GROUP BY attrelid;
|
|
attrelid | array_accum
|
|
----------+------------------------------
|
|
pg_user | {19,23,16,16,16,25,702,1009}
|
|
(1 row)
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
For further details see the
|
|
<xref linkend="sql-createaggregate" endterm="sql-createaggregate-title">
|
|
command.
|
|
</para>
|
|
</sect1>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode:sgml
|
|
sgml-omittag:nil
|
|
sgml-shorttag:t
|
|
sgml-minimize-attributes:nil
|
|
sgml-always-quote-attributes:t
|
|
sgml-indent-step:1
|
|
sgml-indent-data:t
|
|
sgml-parent-document:nil
|
|
sgml-default-dtd-file:"./reference.ced"
|
|
sgml-exposed-tags:nil
|
|
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
-->
|