Re: extend pgbench expressions with functions

Hello Heikki,

>> This patch extends pgbench expression with functions. Currently only one
>> "abs" function is added. The point is rather to bootstrap the
>> infrastructure for other functions (such as hash, random variants...) to
>> be added later.
>
> I think it would actually be good to add at least some of those other 
> functions in the initial patch.

Hmmm, sure. I wanted some feedback on the "how" before doing that, hence 
the infrastructure patch submitted with just one fonction. Obviously I can 
expand, but before that any opinion on the "how"?

For instance I decided against having individual functions recognized by 
the lexer, and to really have an infrastructure for storing, checking and 
adding them without lex/yacc.

> The infrastructure that this patch adds only supports arguments with a 
> single argument, so it won't get us very far.

> Also, will we need non-integer (e.g. string, numeric, whatever) 
> arguments for the functions?

Maybe float *constants* for random exponential & gaussian.

> How about other datatypes for variables in general?

The point is not to develop another full language in pgbench. People can 
do things with PL/pgSQL & server side if it must be really advanced, the 
point is really to facilitate pgbench "simple" scripts.

> Perhaps not, or if we do that can be a separate patch, but it's 
> something to keep in mind. The pgbench script language is evolving into 
> a full-blown Turing-complete programming language...

The point is *NOT* to do that. For Turing, basically you would need while 
or recursion & condition. Currently there is no such thing and not plan 
for such thing, and I do not think it is desirable.

> As an initial list of functions, I'd suggest:
>
> abs(x)

This is the one included in the patch.

> min(x, y, ...)
> max(x, y, ...)

Hmm, varargs...

> random_uniform(min, max)

Ok. probably just "random"?

> random_gaussian(min, max, threshold)
> random_exponential(min, max, threshold)

Hmm, threshold is a float.

> As soon as we add more functions, the way they are documented needs to 
> be reworked too; we'll need to add a table in the manual to list them.

Yep.

-- 
Fabien.