Re: two-argument aggregates and SQL 2003

I wrote:
> ... Polya's Inventors' Paradox states that
> "the more general problem may be easier to solve", and I've found that
> usually holds up in program design too.

While fooling around with the grammar patch that I showed earlier today,
I had an epiphany that might serve as illustration of the above.  We
have traditionally thought of COUNT(*) as an "aggregate over any base
type".  But wouldn't it be cleaner to think of it as an aggregate over
zero inputs?  That would get rid of the rather artificial need to
convert COUNT(*) to COUNT(1).  We would actually have two separate
aggregate functions, which could most accurately be described ascount()count(anyelement)
where the latter is the form that has the behavior of counting the
non-null values of the input.

While this doesn't really simplify nodeAgg.c, it wouldn't add any
complexity either (once the code has been recast to support variable
numbers of arguments).  And it seems to me that it clarifies the
semantics noticeably --- in particular, there'd no longer be this weird
special case that an aggregate over ANY should have a one-input
transition function where everything else takes two-input.  The rule
would be simple: an N-input aggregate uses an N-plus-one-input
transition function.
        regards, tom lane