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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
