From 3651a3e6fb41121f2262577774382e84bf9a3177 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 15 Apr 2006 17:45:46 +0000 Subject: Support the syntax CREATE AGGREGATE aggname (input_type) (parameter_list) along with the old syntax where the input type was named in the parameter list. This fits more naturally with the way that the aggregate is identified in DROP AGGREGATE and other utility commands; furthermore it has a natural extension to handle multiple-input aggregates, where the basetype-parameter method would get ugly. In fact, this commit fixes the grammar and all the utility commands to support multiple-input aggregates; but DefineAggregate rejects it because the executor isn't fixed yet. I didn't do anything about treating agg(*) as a zero-input aggregate instead of artificially making it a one-input aggregate, but that should be considered in combination with supporting multi-input aggregates. --- doc/src/sgml/ref/create_aggregate.sgml | 37 ++++++++++++++++++++++++++++------ doc/src/sgml/xaggr.sgml | 31 ++++++++++++++-------------- 2 files changed, 47 insertions(+), 21 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/ref/create_aggregate.sgml b/doc/src/sgml/ref/create_aggregate.sgml index 70362f65039..5eb0741c9c2 100644 --- a/doc/src/sgml/ref/create_aggregate.sgml +++ b/doc/src/sgml/ref/create_aggregate.sgml @@ -1,5 +1,5 @@ @@ -20,8 +20,18 @@ PostgreSQL documentation +CREATE AGGREGATE name ( input_data_type ) ( + SFUNC = sfunc, + STYPE = state_data_type + [ , FINALFUNC = ffunc ] + [ , INITCOND = initial_condition ] + [ , SORTOP = sort_operator ] +) + +or the old syntax + CREATE AGGREGATE name ( - BASETYPE = input_data_type, + BASETYPE = base_type, SFUNC = sfunc, STYPE = state_data_type [ , FINALFUNC = ffunc ] @@ -87,7 +97,7 @@ CREATE AGGREGATE name ( An aggregate function may provide an initial condition, that is, an initial value for the internal state value. - This is specified and stored in the database as a column of type + This is specified and stored in the database as a value of type text, but it must be a valid external representation of a constant of the state value data type. If it is not supplied then the state value starts out null. @@ -146,8 +156,9 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1; Ordinarily, a data type's < operator is the proper sort operator for MIN, and > is the proper sort operator for MAX. Note that the optimization will never - actually take effect unless the specified operator is the less than or - greater than strategy member of a B-tree index operator class. + actually take effect unless the specified operator is the less + than or greater than strategy member of a B-tree + index operator class. @@ -170,13 +181,27 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1; The input data type on which this aggregate function operates. - This can be specified as "ANY" for an aggregate that + This can be specified as * for an aggregate that does not examine its input values (an example is count(*)). + + base_type + + + In the old syntax for CREATE AGGREGATE, the input data type + is specified by a basetype parameter rather than being + written next to the aggregate name. Note that this syntax allows + only one input parameter. To define an aggregate that does not examine + its input values, specify the basetype as + "ANY" (not *). + + + + sfunc diff --git a/doc/src/sgml/xaggr.sgml b/doc/src/sgml/xaggr.sgml index bbb4055b916..db6c077cbf6 100644 --- a/doc/src/sgml/xaggr.sgml +++ b/doc/src/sgml/xaggr.sgml @@ -1,4 +1,4 @@ - + User-Defined Aggregates @@ -43,23 +43,24 @@ The aggregate definition would be: -CREATE AGGREGATE complex_sum ( +CREATE AGGREGATE sum (complex) +( sfunc = complex_add, - basetype = complex, stype = complex, initcond = '(0,0)' ); -SELECT complex_sum(a) FROM test_complex; +SELECT sum(a) FROM test_complex; - complex_sum -------------- + sum +----------- (34,53.9) - (In practice, we'd just name the aggregate sum and rely on - PostgreSQL to figure out which kind - of sum to apply to a column of type complex.) + (Notice that we are relying on function overloading: there is more than + one aggregate named sum, but + PostgreSQL can figure out which kind + of sum applies to a column of type complex.) @@ -99,9 +100,9 @@ SELECT complex_sum(a) FROM test_complex; looks like: -CREATE AGGREGATE avg ( +CREATE AGGREGATE avg (float8) +( sfunc = float8_accum, - basetype = float8, stype = float8[], finalfunc = float8_avg, initcond = '{0,0}' @@ -116,14 +117,14 @@ CREATE AGGREGATE avg ( See 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 + with a polymorphic input type and state type, allowing a single aggregate definition to serve for multiple input data types. Here is an example of a polymorphic aggregate: -CREATE AGGREGATE array_accum ( +CREATE AGGREGATE array_accum (anyelement) +( sfunc = array_append, - basetype = anyelement, stype = anyarray, initcond = '{}' ); @@ -167,7 +168,7 @@ SELECT attrelid::regclass, array_accum(atttypid) if (fcinfo->context && IsA(fcinfo->context, AggState)) - One reason for checking this is that when it is true, the left input + One reason for checking this is that when it is true, the first input must be a temporary transition value and can therefore safely be modified in-place rather than allocating a new copy. (This is the only case where it is safe for a function to modify a pass-by-reference input.) -- cgit v1.2.3