From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Support the syntax CREATE AGGREGATE aggname (input_type) |
Date: | 2006-04-15 17:45:53 |
Message-ID: | 20060415174553.3A02111F661B@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
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.
Modified Files:
--------------
pgsql/doc/src/sgml/ref:
create_aggregate.sgml (r1.33 -> r1.34)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/create_aggregate.sgml.diff?r1=1.33&r2=1.34)
pgsql/doc/src/sgml:
xaggr.sgml (r1.30 -> r1.31)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/xaggr.sgml.diff?r1=1.30&r2=1.31)
pgsql/src/backend/commands:
aggregatecmds.c (r1.33 -> r1.34)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/aggregatecmds.c.diff?r1=1.33&r2=1.34)
alter.c (r1.18 -> r1.19)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/alter.c.diff?r1=1.18&r2=1.19)
comment.c (r1.88 -> r1.89)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/comment.c.diff?r1=1.88&r2=1.89)
functioncmds.c (r1.73 -> r1.74)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/functioncmds.c.diff?r1=1.73&r2=1.74)
operatorcmds.c (r1.29 -> r1.30)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/operatorcmds.c.diff?r1=1.29&r2=1.30)
pgsql/src/backend/nodes:
copyfuncs.c (r1.332 -> r1.333)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/nodes/copyfuncs.c.diff?r1=1.332&r2=1.333)
equalfuncs.c (r1.268 -> r1.269)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/nodes/equalfuncs.c.diff?r1=1.268&r2=1.269)
pgsql/src/backend/parser:
gram.y (r2.537 -> r2.538)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/gram.y.diff?r1=2.537&r2=2.538)
parse_func.c (r1.185 -> r1.186)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/parse_func.c.diff?r1=1.185&r2=1.186)
pgsql/src/backend/tcop:
utility.c (r1.255 -> r1.256)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/utility.c.diff?r1=1.255&r2=1.256)
pgsql/src/include/commands:
defrem.h (r1.71 -> r1.72)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/commands/defrem.h.diff?r1=1.71&r2=1.72)
pgsql/src/include/nodes:
nodes.h (r1.184 -> r1.185)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/nodes.h.diff?r1=1.184&r2=1.185)
parsenodes.h (r1.306 -> r1.307)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/parsenodes.h.diff?r1=1.306&r2=1.307)
pgsql/src/include/parser:
parse_func.h (r1.55 -> r1.56)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/parser/parse_func.h.diff?r1=1.55&r2=1.56)
pgsql/src/test/regress/expected:
errors.out (r1.51 -> r1.52)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/errors.out.diff?r1=1.51&r2=1.52)
From | Date | Subject | |
---|---|---|---|
Next Message | User Gsmet | 2006-04-15 18:01:30 | pgfouine - www: +s |
Previous Message | User Shachar | 2006-04-15 11:39:43 | oledb - oledb: DBTYPE_BOOL is actually a two word value, and requires |