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

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:
> Subject: [HACKERS] Issues with factorial operator
> I'm working with a customer that recently discovered that some code
> generated the following nice query...
> SELECT ... WHERE table_id = 92838278! AND ...
> So their production server now has several processes that are trying
> 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);
> 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
> without any precision or scale creates a column in which numeric
> of any precision and scale can be stored, up to the implementation
> on precision.
> Yet here we have a numeric that's storing nearly 10,000 digits of
> precision.
> --
> Jim Nasby                                      [EMAIL PROTECTED]
> EnterpriseDB      512.569.9461 (cell)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to