Re: two-argument aggregates and SQL 2003

I wrote [ in an off-list reply to Mark Dilger ]:
> I don't think this solves the parsing problem at all. The problem as I
> see it is that given
> CREATE AGGREGATE foo (bar ...
> it's not obvious whether bar is a def_elem name (old syntax) or a type
> name (new syntax). It's possible that we can get bison to eat both
> anyway on the basis that the lookahead token must be '=' at this point
> for old syntax while it could not be '=' for new syntax.

I did some idle investigation of this and found that it's indeed
possible, as long as we make the further restriction that none of the
definition-list keywords used by old-style CREATE AGGREGATE be keywords
of the SQL grammar. (We could probably allow selected ones if we had
to, but using ColLabel rather than IDENT in the patch below leads to
tons of reduce/reduce conflicts...) Attached is a proof-of-concept
patch, which doesn't do anything useful as-is because none of the rest
of the backend has been updated, but it does prove that bison can be
made to handle CREATE AGGREGATE syntax with an initial list of type
names. For instance the first example in
http://www.postgresql.org/docs/8.1/static/xaggr.html
would become

CREATE AGGREGATE complex_sum (complex)
(
sfunc = complex_add,
stype = complex,
initcond = '(0,0)'
);

I'm inclined to flesh this out and apply it with or without any further
work by Sergey, simply because it makes the syntax of CREATE AGGREGATE
more in harmony with DROP AGGREGATE and the other AGGREGATE commands.
Any objections out there?

Another thing we could look into is doing something similar to CREATE
OPERATOR, so that it names the new operator the same way you would do
in DROP OPERATOR. Not sure if this is worth the trouble or not, as
I don't find DROP OPERATOR amazingly intuitive.

regards, tom lane