Re: [HACKERS] pgbench more operators & functions

Hello Teodor,

>>> It may be good for 't' of 'f' but it seems too free grammar to accept 'tr' 
>>> or 'fa' or even 'o' which actually not known to be on or off.
>> 
>> Yes, it really works like that. I tried to make something clearer than 
>> "src/bin/psql/variable.c". Maybe I did not succeed.

> Ok, I see. Current coding accepts truexxx, falsexxx, yesxx, noxxx but doesn't 
> accept offxxx and onxxx. Not so consistent as it could be.

I've checked, but truexxx is not accepted as true. I have added a test 
case which fails on "malformed variable", i.e. it went up to scanning a 
double. When comparing ("truexxx", "true", 7) the fifth char is different, 
so it is != 0. Or I'm missing something.

> Also it doesn't accept 1 and 0 as psql does, but it's obviously why.

Yep. I have added a comment that it will be an int, and if a boolean is 
needed it would work as expected.

> Sorry, but I found more notices:
> 1) '~' and unary '-' should be commented, it's not so easy to guess about how 
> they actually implemented (-1 XOR value, remember that -1 is 0xfffff....)

Ok, I agree that it looks strange. I have added comments for both. I have 
replaced -1 by 0xffff.... so that the code is hopefully clearer.

> 2)
> -   | expr '%' expr         { $$ = make_op(yyscanner, "%", $1, $3); }
> +   | expr '%' expr         { $$ = make_op(yyscanner, "mod", $1, $3); }
>
> why is MOD operation renamed? Do I miss something in thread?

Because I have added MOD as an explicit function to match SQL, so now % is 
just a shorthand for calling it. Before the patch there was only the '%' 
operator. Changing the name is enough for the function to be found.

   pg> SELECT 11 % 3, MOD(11, 3);
   2 | 2

> Looking to psql and pgbench scripting implementation, isn't it better to 
> integrate lua in psql & pgbench?

Hmmm... if it starts on this slope, everyone will have its opinion (lua, 
tcl, python, ruby, perl, insert-script-name-here...) and it must interact 
with SQL, I'm not sure how to embed SQL & another language cleanly. So the 
idea is just to extend backslash command capabilities of psql & pgbench, 
preferably consistently, when need (i.e. use cases) arises.

Attached a new version with these changes.

-- 
Fabien.