Hello Alvaro,
For instance for "random_gaussian(int, int, double)", it may be called with
any combination of 3 int/double arguments, each one must be tested and
possibly converted to the target type before calling the actual function.
For overloaded operators or functions (arithmetics, abs...) there is also
the decision about which operator is called and then what conversions are
necessary.
I think we should make this as simple as possible -- in particular I
don't see a lot of value in overloading here. I'd rather have it throw
an error and force you to write the double with a ".0" when the given
value is an integer so that it is parsed as a double, rather than
accepting ambiguous input. Conversely, if you pass a double to the
integer options, raise an error.
I agree that the overloading and other stuff is not a decisive and very
useful feature of the patch, but I think that the descendant-typing
two-functions recursive evaluation is a good compromise, as it works
without much ado nor ambiguity, and from my point of view the code stays
quite simple with this approach.
So although the benefit (of having overloaded operators and handling two
types expressions) is indeed in practice quite limited, the cost in the
code is low.
Being more restrictive or strict as you suggest would not remove much
code, and would remove some convenience. Also, removing this feature would
induce inconsistencies: integer arguments would allow general expressions,
but only double constants would be ok for double arguments...
So I would rather keep it as it is.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
