> 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/