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

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