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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
