Patch attached and applied. Thanks.
I adjusted the oid so prevent a duplicate, and adjusted the regression
test to remove comments on now non-existant functions.
I also tested the output and it looks good:
test=> select numeric_fac(10);
numeric_fac
---
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Gavin Sherry wrote:
> On Thu, 31 Jul 2003
On Thu, 31 Jul 2003, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > What are your feelings about numeric argument vs. int4/int8 arguments?
>
> Actually I think it'd be fine to take int8. We'd not be able to cope
> with any larger input anyway, and the inner loop could be noticeab
Gavin Sherry <[EMAIL PROTECTED]> writes:
> What are your feelings about numeric argument vs. int4/int8 arguments?
Actually I think it'd be fine to take int8. We'd not be able to cope
with any larger input anyway, and the inner loop could be noticeably
faster if the control logic just deals with i
On Thu, 31 Jul 2003, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > 2) since we're accepting numeric arguments, the patch tests for floats. If
> > a numeric is passed with non-zero decimal portion, an error is raised
> > since (from memory) they are undefined.
>
> There is a stand
Gavin Sherry <[EMAIL PROTECTED]> writes:
> 2) since we're accepting numeric arguments, the patch tests for floats. If
> a numeric is passed with non-zero decimal portion, an error is raised
> since (from memory) they are undefined.
There is a standard mathematical definition for it (gamma function
Attached is a patch implementing factorial(), returning numeric. Points to
note:
1) arttype is numeric. I thought this was the best way of allowing
arbitarily large factorials, even though factorial(2^63) is a large
number. Happy to change to integers if this is overkill.
2) since we're accepting