> > -- there isn't a floating point factorial operator...
> > tgl=> select (4.3 !);
> > ?column?
> > --------
> > 24
> > (1 row)
>
> Am I the only one that thinks the above is wrong? 4.3 factorial is
> mathematically undefined and does NOT equal 24.
>
> I don't think the automatic type conversion should automatically
> truncate values without at least a warning. Preferably I'd like to be
> forced to do the conversion myself for cases like the above.
Yes, I included this one to provoke discussion :)
Postgres has type extensibility, so the algorithms for matching up types
and functions need to be very general. In this case, there is only one
function defined for factorial, and it takes an integer argument. But of
course Postgres now says "ah! I know how to make an int from a float!"
and goes ahead and does it. If there were more than one function defined
for factorial, and if none of the arguments matched a float, then
Postgres would conclude that there are too many functions to choose from
and throw an error.
One way to address this is to never allow Postgres to "demote" a type;
i.e. Postgres would be allowed to promote arguments to a "higher" type
(e.g. int->float) but never allowed to demote arguments (e.g.
float->int). But this would severely restrict type matching. I wanted to
try the more flexible case first to see whether it really does the
"wrong thing"; in the case of factorial, the only recourse for someone
wanting to calculate a factorial from a float is to convert to an int
first anyway.
Or, again for this factorial case, we can implement a floating point
factorial with either the gamma function (whatever that is :) or with an
explicit routine which checks for non-integral values.
Could also print a notice when arguments are being converted, but that
might get annoying for most cases which are probably trivial ones.
- Tom