Re: extend pgbench expressions with functions
От | Fabien COELHO |
---|---|
Тема | Re: extend pgbench expressions with functions |
Дата | |
Msg-id | alpine.DEB.2.10.1511041614320.16208@sto обсуждение исходный текст |
Ответ на | Re: extend pgbench expressions with functions (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: