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

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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to