> Now I understand what Alex Thurgood wanted to tell me, I didn't know
> that notation at all. But as I see know it's documented in the help.
>
> But anyways, the Date sign "D" always occurs only inside a pair of curly
> brackets if I understand correctly. The parser could (and should) sort
> this out. I use alphabetical column names very often.
>
> Maybe I'll file an Issue for that one, it would have saved a big amount
> of time knowing earlier.
While speaking about funny parser problems...
While parsing
SELECT * FROM addresses WHERE "Mobile Phone" IS NOT NULL
the condition "IS NOT NULL" is not recognized because the tokens are one unit
less than the expected values:
const OSQLParseNode
*p1 = pParseNode->getChild(0), // "Mobile Phone"
*p2 = pParseNode->getChild(1), // IS
*p3 = pParseNode->getChild(2), // NOT
*p4 = pParseNode->getChild(3); // NULL
printf("%d %d %d\n", SQL_TOKEN_IS, SQL_TOKEN_NOT, SQL_TOKEN_NULL);
printf("%d %d\n", p2->getTokenID(), SQL_ISTOKEN(p2, IS));
printf("%d %d\n", p3->getTokenID(), SQL_ISTOKEN(p3, NOT));
printf("%d %d\n", p4->getTokenID(), SQL_ISTOKEN(p4, NULL));
=>
323 264 335
322 0
263 0
334 0
Perharps the problem is on my side (memory corruption, some misunderstanding
of how the parser is supposed to work, bad version of "bison" package), but
the problem could be in the parser too (bad initialisation of an
enumeration, ...)
I will have no time to file an issue for that problem (if confirmed) before
Tuesday.
If this problem is real, IS NOT NULL should not work anymore with Mozilla
driver, for example.
The column description (pointed to by p1 in the above code) has no problem.
Environment : m122 on a Linux Box,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
