Re: two-argument aggregates and SQL 2003

On Sat, Apr 15, 2006 at 12:51:24AM -0400, Tom Lane wrote:
> 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 as
>     count()
>     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.

Speaking strictly from a users PoV, I'm not sure this is a great idea,
since it encourages non-standard code (AFAIK no one else accepts
'count()'), and getting rid of support for count(*) seems like a
non-starter, so I'm not sure there's any benefit.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461