Re: Issues with factorial operator

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: pgsql-hackers-owner(at)postgresql(dot)org [mailto:pgsql-hackers-
> owner(at)postgresql(dot)org] On Behalf Of Jim C. Nasby
> Sent: Friday, June 08, 2007 6:45 PM
> To: pgsql-hackers(at)postgresql(dot)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 decibel(at)decibel(dot)org
> EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)