Re: [HACKERS] pgbench more operators & functions

> 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.
Oh, my fault. I've missed that. Thank you for test

> 
> 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.
I changed 0xff constant  to  ~INT64CONST(0), seems, it's more consistent way.
Also I remove some whitespaces in exprparse.y. Fixed version in attachment.
> 
>> 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.

Actually, I prefer to see single scripting implementation in both psql and 
pgbench, but I suppose nobody has a power to do it in foreseen future. And, may 
be, it's not a very good way  to invent one script language instead of using one 
of bunch of them, but, again, I'm afraid several months/years discussion about 
how and which one to embed. But scripting is needed now, I believe, at least I 
see several test scenarios which can not be implemented with current pgbench and 
this patch allows to do it.

So, I intend to push thish patch in current state. I saw several objections from 
commiters in thread, but, seems, that objections are lifted. Am I right?

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/