Hello Robert,
> Writing a simple expression parser for pgbench using flex and bison
> would not be an inordinately difficult problem.
Sure. Note that there is not only the parsing but also the evaluating to
think of, which mean a data structure to represent the expressions which
would be more complex than the current one. Although it is not difficult
as such, it would mean breaking pgbench heavily, which would mean
more time and energy than I have available.
> And it would let you add abs() and ?: and thereby avoid the need to
> hard-code multiple versions of the modulo operator in the patch.
It would also mean to *implement* abs and ?: in the "execution" code to
compute the parsed expression.
> The fact that you're agonizing about which modulo to add is a sign that
> the language is too impoverished to let you do anything non-trivial.
I'm not agonizing about which modulo to use:-) I know I do not want the
C/SQL version which is never really useful if you have signed data. I
overlooked this detail when submitting the first patch, and produced a
stupid patch with all 3 possible modulos, before going to the sane
solution which is to use the floored division Knuth version. If I had
thought a bit, I would have sent v3 as v1 directly.
> That's why C only has one modulo operator: as the patch demonstrates,
> the differences between the version can be patched over with a very
> short C expression. If we had real expressions in pgbench, you could do
> the same thing there.
Sure. I agree that pgbench is limited and that real expressions would have
helped, but it is also quite useful and easy to extend "as is". Maybe the
"add an expression parser to pgbench" could be added in the postgresql
todo wiki?
--
Fabien.