Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 3651a3e

Browse files
tglsfdctglsfdc
committed
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.
1 parent ebd5257 commit 3651a3e

File tree

17 files changed

+395
-351
lines changed

17 files changed

+395
-351
lines changed

‎doc/src/sgml/ref/create_aggregate.sgml

Lines changed: 31 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.33 2005/11/04 23:14:02 petere Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/ref/create_aggregate.sgml,v 1.34 2006/04/15 17:45:18 tgl Exp $
33
PostgreSQL documentation
44
-->
55

@@ -20,8 +20,18 @@ PostgreSQL documentation
2020

2121
<refsynopsisdiv>
2222
<synopsis>
23+
CREATE AGGREGATE <replaceable class="PARAMETER">name</replaceable> ( <replaceable class="PARAMETER">input_data_type</replaceable> ) (
24+
SFUNC = <replaceable class="PARAMETER">sfunc</replaceable>,
25+
STYPE = <replaceable class="PARAMETER">state_data_type</replaceable>
26+
[ , FINALFUNC = <replaceable class="PARAMETER">ffunc</replaceable> ]
27+
[ , INITCOND = <replaceable class="PARAMETER">initial_condition</replaceable> ]
28+
[ , SORTOP = <replaceable class="PARAMETER">sort_operator</replaceable> ]
29+
)
30+
31+
or the old syntax
32+
2333
CREATE AGGREGATE <replaceable class="PARAMETER">name</replaceable> (
24-
BASETYPE = <replaceable class="PARAMETER">input_data_type</replaceable>,
34+
BASETYPE = <replaceable class="PARAMETER">base_type</replaceable>,
2535
SFUNC = <replaceable class="PARAMETER">sfunc</replaceable>,
2636
STYPE = <replaceable class="PARAMETER">state_data_type</replaceable>
2737
[ , FINALFUNC = <replaceable class="PARAMETER">ffunc</replaceable> ]
@@ -87,7 +97,7 @@ CREATE AGGREGATE <replaceable class="PARAMETER">name</replaceable> (
8797
<para>
8898
An aggregate function may provide an initial condition,
8999
that is, an initial value for the internal state value.
90-
This is specified and stored in the database as a column of type
100+
This is specified and stored in the database as a value of type
91101
<type>text</type>, but it must be a valid external representation
92102
of a constant of the state value data type. If it is not supplied
93103
then the state value starts out null.
@@ -146,8 +156,9 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1;
146156
Ordinarily, a data type's <literal>&lt;</> operator is the proper sort
147157
operator for <function>MIN</>, and <literal>&gt;</> is the proper sort
148158
operator for <function>MAX</>. Note that the optimization will never
149-
actually take effect unless the specified operator is the <quote>less than</quote> or
150-
<quote>greater than</quote> strategy member of a B-tree index operator class.
159+
actually take effect unless the specified operator is the <quote>less
160+
than</quote> or <quote>greater than</quote> strategy member of a B-tree
161+
index operator class.
151162
</para>
152163
</refsect1>
153164

@@ -170,13 +181,27 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1;
170181
<listitem>
171182
<para>
172183
The input data type on which this aggregate function operates.
173-
This can be specified as <literal>"ANY"</> for an aggregate that
184+
This can be specified as <literal>*</> for an aggregate that
174185
does not examine its input values (an example is
175186
<function>count(*)</function>).
176187
</para>
177188
</listitem>
178189
</varlistentry>
179190

191+
<varlistentry>
192+
<term><replaceable class="PARAMETER">base_type</replaceable></term>
193+
<listitem>
194+
<para>
195+
In the old syntax for <command>CREATE AGGREGATE</>, the input data type
196+
is specified by a <literal>basetype</> parameter rather than being
197+
written next to the aggregate name. Note that this syntax allows
198+
only one input parameter. To define an aggregate that does not examine
199+
its input values, specify the <literal>basetype</> as
200+
<literal>"ANY"</> (not <literal>*</>).
201+
</para>
202+
</listitem>
203+
</varlistentry>
204+
180205
<varlistentry>
181206
<term><replaceable class="PARAMETER">sfunc</replaceable></term>
182207
<listitem>

‎doc/src/sgml/xaggr.sgml

Lines changed: 16 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/xaggr.sgml,v 1.30 2006/03/10 19:10:49 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/xaggr.sgml,v 1.31 2006/04/15 17:45:33 tgl Exp $ -->
22

33
<sect1 id="xaggr">
44
<title>User-Defined Aggregates</title>
@@ -43,23 +43,24 @@
4343
The aggregate definition would be:
4444

4545
<screen>
46-
CREATE AGGREGATE complex_sum (
46+
CREATE AGGREGATE sum (complex)
47+
(
4748
sfunc = complex_add,
48-
basetype = complex,
4949
stype = complex,
5050
initcond = '(0,0)'
5151
);
5252

53-
SELECT complex_sum(a) FROM test_complex;
53+
SELECT sum(a) FROM test_complex;
5454

55-
complex_sum
56-
-------------
55+
sum
56+
-----------
5757
(34,53.9)
5858
</screen>
5959

60-
(In practice, we'd just name the aggregate <function>sum</function> and rely on
61-
<productname>PostgreSQL</productname> to figure out which kind
62-
of sum to apply to a column of type <type>complex</type>.)
60+
(Notice that we are relying on function overloading: there is more than
61+
one aggregate named <function>sum</>, but
62+
<productname>PostgreSQL</productname> can figure out which kind
63+
of sum applies to a column of type <type>complex</type>.)
6364
</para>
6465

6566
<para>
@@ -99,9 +100,9 @@ SELECT complex_sum(a) FROM test_complex;
99100
looks like:
100101

101102
<programlisting>
102-
CREATE AGGREGATE avg (
103+
CREATE AGGREGATE avg (float8)
104+
(
103105
sfunc = float8_accum,
104-
basetype = float8,
105106
stype = float8[],
106107
finalfunc = float8_avg,
107108
initcond = '{0,0}'
@@ -116,14 +117,14 @@ CREATE AGGREGATE avg (
116117
See <xref linkend="extend-types-polymorphic">
117118
for an explanation of polymorphic functions.
118119
Going a step further, the aggregate function itself may be specified
119-
with a polymorphic base type and state type, allowing a single
120+
with a polymorphic input type and state type, allowing a single
120121
aggregate definition to serve for multiple input data types.
121122
Here is an example of a polymorphic aggregate:
122123

123124
<programlisting>
124-
CREATE AGGREGATE array_accum (
125+
CREATE AGGREGATE array_accum (anyelement)
126+
(
125127
sfunc = array_append,
126-
basetype = anyelement,
127128
stype = anyarray,
128129
initcond = '{}'
129130
);
@@ -167,7 +168,7 @@ SELECT attrelid::regclass, array_accum(atttypid)
167168
<programlisting>
168169
if (fcinfo->context &amp;&amp; IsA(fcinfo->context, AggState))
169170
</programlisting>
170-
One reason for checking this is that when it is true, the left input
171+
One reason for checking this is that when it is true, the first input
171172
must be a temporary transition value and can therefore safely be modified
172173
in-place rather than allocating a new copy. (This is the <emphasis>only</>
173174
case where it is safe for a function to modify a pass-by-reference input.)

0 commit comments

Comments
 (0)