>
>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.
Making an int from a float is only defined for "small" values of the float.
So for the general case such a conversion would simply overflow the int,
giving it an undefined value. Does this make sense to you?
>
>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.
Please bear with me since I haven't looked at the code. Are conversions
between types defined in a way that is also extensible? I'm trying to say
that if I add a new type to the system, can I also specify which conversions
are automatically allowed? (Something similar to the C++ "explicite"
keyword?).
>
>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.
And properly handles overflows.
>
>Could also print a notice when arguments are being converted, but that
>might get annoying for most cases which are probably trivial ones.
>
> - Tom
Regards,
Maurice.