"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> 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.
This documentation is outright wrong. The grain of truth behind the
statement is that the
yeah, simple and correct, I like that. :-)
2007/6/9, Dann Corbit <[EMAIL PROTECTED]>:
> -Original Message-
[snip]
> Hum... I think there is a little improvement: when n is too large,(say
> n>10, 000) we can use Stirling's formula to get the estimated value of
> n!:-)
Or (rather) the
> -Original Message-
[snip]
> Hum... I think there is a little improvement: when n is too large,(say
> n>10, 000) we can use Stirling's formula to get the estimated value of
> n!:-)
Or (rather) the log base 10 of Stirling's formula. The n! estimator
will overflow for sure, unless we t
2007/6/9, Dann Corbit <[EMAIL PROTECTED]>:
#include
double log10nfactorialestimate(unsigned n)
{
unsignedi;
double estimate = 0;
for (i = 1; i < n; i++)
estimate += log10(n);
return estimate;
}
#ifdef UNIT_TEST
#include
#include
int
> -Original Message-
> From: Cui Shijun [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 08, 2007 11:11 PM
> To: Dann Corbit
> Cc: Jim C. Nasby; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Issues with factorial operator
>
> Hi,
>
> 2007/6/9,
Hi,
2007/6/9, Dann Corbit <[EMAIL PROTECTED]>:
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.
well, in fact what we need is to calculate log10(n!) first to see if
the result will get ex
-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 cus
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) t
