Hello Kyotaro-san,
> My description should have been obscure. Indeed the call tree is
> finite for *sane* expression node. But it makes infinit call for
> a value of expr->etype unknown by both evalDouble and
> evalInt.
Such issue would be detected if the function is actually tested, hopefully
this should be the case... :-)
However I agree that relying implicitely on the "default" case is not very
good practice, so I updated the code in the attached v11 to fail
explicitely on such errors.
I also attached a small test script, which exercises most (all?)
functions:
./pgbench -f functions.sql -t 1
> [...]
> By the way, the complexity comes from separating integer and
> double. If there is no serios reason to separate them, handling
> all values as double makes things far simpler.
Yep, but no.
> Could you let me know the reason why it strictly separates integer and
> double? I don't see no problem in possible errors of floating point
> calculations for this purpose. Is there any?
Indeed it would make things simpler, but it would break large integers as
the int64 -> double -> int64 casts would result in approximations. The
integer type is the important one here because it is used for primary
keys, and you do not want a key to be approximated in any way, so the
int64 type must be fully and exactly supported.
--
Fabien.
