Re: SQL (was: Why using "Group By")

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 15 Mar 2003 02:06:07 -0500
Message-ID: <ILAca.80$2x5.7989286_at_mantis.golden.net>


"Mikito Harakiri" <mikharakiri_at_yeehu.com> wrote in message news:w2zca.108280$sf5.64676_at_rwcrnsc52.ops.asp.att.net...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:7Eyca.74$ij5.7409791_at_mantis.golden.net...
> > > > Do you have an example problem requiring recursion for which
> transitive
> > > > closure provides no solution?
> > >
> > > Please express 5! via transitive closure. You are not allowed to
> represent
> > > multiplication as sum of logariphms (you wouldn't use transitive
closure
> > > with that approach, anyway). My solution
> > >
> > > select
> > > case when prior factorial is NULL then 1 else prior factorial*i end
AS
> > > factorial
> > > from integers
> > > order by i
> >
> > product((Integer | value between 1 and 5 ){value})
> >
> > I don't need any kind of recursion for that simple problem.
>
> Where "product" is user defined summarize function?

Product is a well-defined aggregate function. I am continually amazed that SQL doesn't include it. I am even more surprised that Tutorial D does not include it, but, then again, I don't think D prohibits it either. Were I to develop an rdbms, the product aggregate would be a built-in aggregate function.

I've only had a couple times in my career when it would have been useful, but it would have been damned useful !

> The point of the
> exercise was to keep procedural code to absolute minimum. OK, how about
> Greatest Common Divisor? (and, of course, Ackermann function is next;-)

I thought the point of the exercise was to identify a need for recursion.

Ackermann is a simple addition. GCD may be an excellent example requiring recursion--in any case, I am too tired right now to think of an objection.

I'll simply concede a need for recursion. Received on Sat Mar 15 2003 - 08:06:07 CET

Original text of this message