It makes sense with factorial function to do an error check on the domain. Calculate beforehand, and figure out what the largest sensible domain value is.
For instance, in Maple, I get this: > y:=92838278!; Error, object too large > The error message returns instantly. For reasonably large values, it might make sense to pre-compute factorials and store them in an array. It should also be possible to store 1/2 of Pascal's triangle in memory and demand load that memory segment the first time someone asks for factorials or combinations or permutations. Just a thought. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:pgsql-hackers- > [EMAIL PROTECTED] On Behalf Of Jim C. Nasby > Sent: Friday, June 08, 2007 6:45 PM > To: pgsql-hackers@postgresql.org > Subject: [HACKERS] Issues with factorial operator > > I'm working with a customer that recently discovered that some code had > generated the following nice query... > > SELECT ... WHERE table_id = 92838278! AND ... > > So their production server now has several processes that are trying to > compute some absurdly large factorial. There's two issues here: > > 1) the computation doesn't check for signals. This means both a plain > kill and pg_cancel_backend() are useless. > > 2) Even though the answer is going to be an obscene number of digits, > and that's supposed to be fed into a numeric, there's no overflow or > bounds checking occurring. This is true even if I store into a field > defined as numeric: > > decibel=# create table n(n numeric); > CREATE TABLE > decibel=# insert into n select 3333!; > INSERT 0 1 > decibel=# select char_length(trim(n, '0')) from n; > char_length > ------------- > 9466 > (1 row) > > So at the very least the documentation is confusing: > > The type numeric can store numbers with up to 1000 digits of precision > and perform calculations exactly. > ... > Specifying > > NUMERIC > > without any precision or scale creates a column in which numeric values > of any precision and scale can be stored, up to the implementation limit > on precision. > > Yet here we have a numeric that's storing nearly 10,000 digits of > precision. > -- > Jim Nasby [EMAIL PROTECTED] > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
