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
