Re: extend pgbench expressions with functions

Hello Kyotaro-san,

> 1.evalInt and evalDouble are mutually calling on single expr
> node.

Indeed.

> It looks simple and seems to work but could easily broken
> to fall into infinite call and finally (in a moment) exceeds
> stack depth.

The recursion is on the tree-structure of the expression, which is 
evaluated depth-first. As the tree must be finite, and there is no such 
thing as recursive functions in the expression tree, this should never 
happen. If it happened, it would be a bug in the eval functions, probably 
a forgotten "case", and could be fixed there easily.

> I think it is better not to do so. For example, reunioning
> evalDouble and evalInt into one evalulateExpr() which can return
> both double and int result would do so. The interface would be
> something like the follwings or others. Some individual
> functions might be better to be split out.
>
>  static ExprRetType evaluateExpr(TState,CState,PgBenchExpr,
>                                  int *iret, double *dret);

That would not work as simply as that: this signature does not say whether 
a double or an int is expected, and without this information you would not 
know what to do on some operators (the typing is explicit and descendant 
in the current implementation).

Even if you add this information, or you use the returned type information 
to do the typing dynamically, that would mean testing the result types and 
implementing the necessary casts depending on this information for every 
function within the generic eval, which would result in repetitive and 
ugly code for every function and operator: for instance for '+', you would 
have to implement 4 cases explicitely, i+i, f+i, i+f, f+f as "int add", 
"cast left and double add", "cast right and double add", and finally 
"double add". Then you have other operators to consider... Although some 
sharing can be done, this would end in lengthy & ugly code.

A possible alternative could be to explicitely and statically type all 
operations, adding the necessary casts explicitely, distinguishing 
operators, but the would mean more non-obvious code to "compile" the 
parsed expressions, I'm not sure that pgbench deserves this.

The two eval functions and the descendant typing allow to hide/ignore 
these issues because each eval function handles just one type, type 
boundaries are explicitely handled by calling the other function, so there 
is no reason to test and cast everything all the time.

So I thing that it would not be an improvement to try to go the way you 
suggest.

> 2. You combined abs/sqrt/ddebug and then make a branch for
>  them. It'd be better to split them even if eval*() looks to be
>  duplicate.

Hm, why not.

Here is a v10 where I did that when it did not add too much code 
repetition (eg I kept the shared branches for MIN & MAX and for the 3 
RANDOM functions so as to avoid large copy pastes).

-- 
Fabien.