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.
