Parser does not produce UPDATE section if table name is reserved word

[GoogleCodeExporter]

What steps will reproduce the problem?
Parse the following query:
UPDATE user SET lastlogin = 7, x = 3; 

What is the expected output? What do you see instead?
I expected the 'UPDATE' section to be present in the parsed member.
The 'UPDATE' section is wholly missing, only the 'SET' section exists.
Changing table name to 'users' works correctly, so it seems to be an issue with 
the table name being a reserved word. The query runs fine on MySQL 5.x

What version of the product are you using? On what operating system?
Downloaded 2/29/2012. PHP 5.3.5 on 64-bit ubuntu Linux.

Please provide any additional information below.

Original issue reported on code.google.com by boa...@gmail.com on 1 Mar 2012 at 10:29

[GoogleCodeExporter]

The parser tries to recognize keywords in the first step. It splits the main 
parts of a query on this keywords. So, if you use a keyword within your query, 
on this early step the parser has no chance to see, that it is not a real 
keyword (in your case a table name). The only solution is to implement more 
logic in this step, so the parser will not use USER if it knows already UPDATE. 
I'll se, what I can do.

Original comment by pho...@gmx.de on 2 Mar 2012 at 7:46

[GoogleCodeExporter]

I have fixed this specific problem. The keyword USER will recognize, if the 
previous keyword is one of RENAME, CREATE or DROP. In all other cases it is 
used as normal token (like tablename or alias). Other keywords can break the 
parser, this is a base problem of the parser. It can only be solved with a 
validating parser and a complete grammar of the MySQL dialect.

Try bleeding edge on https://www.phosco.info/publicsvn/php-sql-parser/trunk

Original comment by pho...@gmx.de on 4 Mar 2012 at 9:04

[GoogleCodeExporter]

Check out the current version on Google.Code, there is a test case for the 
issue.
Thanks for reporting.

Original comment by pho...@gmx.de on 13 Mar 2012 at 12:10

• Changed state: Fixed