Relating to bug [1] the libraries/sqlparser.lib.php PMA_SQPdata_reserved_word list appears to be inconsistent with the list in [2]. I would like know from the developers whether there is a reason for this issues or is it an error in the reserved word list.
Regards Supun
[1] #3942 warnings about reserved word for many non reserved words [2] http://dev.mysql.com/doc/refman/5.5/en/reserved-words.html
On Mon, May 20, 2013 at 5:02 PM, Supun Nakandala supun.nakandala@gmail.comwrote:
Relating to bug [1] the libraries/sqlparser.lib.php PMA_SQPdata_reserved_word list appears to be inconsistent with the list in [2]. I would like know from the developers whether there is a reason for this issues or is it an error in the reserved word list.
The accepted answer to this question on Stackoverflow [1] might be useful.
[1] http://stackoverflow.com/questions/16593166/is-type-and-status-a-reserved-wo...
Madhura Jayaratne a écrit :
On Mon, May 20, 2013 at 5:02 PM, Supun Nakandala supun.nakandala@gmail.comwrote:
Relating to bug [1] the libraries/sqlparser.lib.php PMA_SQPdata_reserved_word list appears to be inconsistent with the list in [2]. I would like know from the developers whether there is a reason for this issues or is it an error in the reserved word list.
The accepted answer to this question on Stackoverflow [1] might be useful.
[1] http://stackoverflow.com/questions/16593166/is-type-and-status-a-reserved-wo...
We should probably review the list of reserved words to ensure that they correspond exactly to the list(s) in the MySQL manual.
The downside of this would be that the syntax highlighter (not the one when editing a query) would no longer highlight these words, but to fix this, the analyzer needs serious work.
My dream solution would be this: call CodeMirror to produce the syntax highlighting everytime, and get rid of our own code for this.
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
We should probably review the list of reserved words to ensure that they correspond exactly to the list(s) in the MySQL manual.
Or at least create separate list for the warning if no other fix is found for 4.0.
The downside of this would be that the syntax highlighter (not the one when editing a query) would no longer highlight these words, but to fix this, the analyzer needs serious work.
Are you sure it would break only highlighting? For me the SQL parser/analyzer was piece of code I never wanted to touch too much :-).
My dream solution would be this: call CodeMirror to produce the syntax highlighting everytime, and get rid of our own code for this.
This should not be that hard - the biggest concern here always was javascript requirement, which is now true anyway...
Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
We should probably review the list of reserved words to ensure that they correspond exactly to the list(s) in the MySQL manual.
Or at least create separate list for the warning if no other fix is found for 4.0.
The downside of this would be that the syntax highlighter (not the one when editing a query) would no longer highlight these words, but to fix this, the analyzer needs serious work.
Are you sure it would break only highlighting? For me the SQL parser/analyzer was piece of code I never wanted to touch too much :-).
git grep reservedWord
shows a few other places to check
My dream solution would be this: call CodeMirror to produce the syntax highlighting everytime, and get rid of our own code for this.
This should not be that hard - the biggest concern here always was javascript requirement, which is now true anyway...
Hi
Dne Mon, 20 May 2013 13:58:02 -0400 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
We should probably review the list of reserved words to ensure that they correspond exactly to the list(s) in the MySQL manual.
Or at least create separate list for the warning if no other fix is found for 4.0.
The downside of this would be that the syntax highlighter (not the one when editing a query) would no longer highlight these words, but to fix this, the analyzer needs serious work.
Are you sure it would break only highlighting? For me the SQL parser/analyzer was piece of code I never wanted to touch too much :-).
git grep reservedWord
shows a few other places to check
Well the question I meant was rather: Will changing this list affect other uses of the analyzer? It's used to detect type of queries and maybe some other stuff (adding LIMIT clause?).
Le 2013-05-21 03:17, Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 13:58:02 -0400 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
We should probably review the list of reserved words to ensure that they correspond exactly to the list(s) in the MySQL manual.
Or at least create separate list for the warning if no other fix is found for 4.0.
The downside of this would be that the syntax highlighter (not the one when editing a query) would no longer highlight these words, but to fix this, the analyzer needs serious work.
Are you sure it would break only highlighting? For me the SQL parser/analyzer was piece of code I never wanted to touch too much :-).
git grep reservedWord
shows a few other places to check
Well the question I meant was rather: Will changing this list affect other uses of the analyzer? It's used to detect type of queries and maybe some other stuff (adding LIMIT clause?).
I think that git grep reservedWord should show all places where a word from this list is used.
In sqlparser.lib.php, we look for explicit words like DELETE, UPDATE etc so the list of reserved words is not used for this. The LIMIT clause is built by looking for LIMIT and OFFSET, not with the reserved words list.
Le 2013-05-21 03:17, Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 13:58:02 -0400 Marc Delisle marc@infomarc.info napsal(a):
Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
We should probably review the list of reserved words to ensure that they correspond exactly to the list(s) in the MySQL manual.
Or at least create separate list for the warning if no other fix is found for 4.0.
The downside of this would be that the syntax highlighter (not the one when editing a query) would no longer highlight these words, but to fix this, the analyzer needs serious work.
Are you sure it would break only highlighting? For me the SQL parser/analyzer was piece of code I never wanted to touch too much :-).
git grep reservedWord
shows a few other places to check
Well the question I meant was rather: Will changing this list affect other uses of the analyzer? It's used to detect type of queries and maybe some other stuff (adding LIMIT clause?).
Removing words like LIMIT, SELECT, UPDATE, etc from the list would cause a problem, but these words are in the official MySQL list.
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
My dream solution would be this: call CodeMirror to produce the syntax highlighting everytime, and get rid of our own code for this.
See https://github.com/phpmyadmin/phpmyadmin/pull/399
Le 2013-05-21 04:07, Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 11:55:26 -0400 Marc Delisle marc@infomarc.info napsal(a):
My dream solution would be this: call CodeMirror to produce the syntax highlighting everytime, and get rid of our own code for this.
Your pull request targets master and I've sent comments for it. When it's ready, do you feel that this patch belongs to 4.0?
If we don't use CodeMirror for highlighting in 4.0, I suggest we remove these incorrect reserved words for 4.0, even if this will break highlighting, because getting false warnings about reserved words is worse that incorrect hightlighting.
Hi
Dne Thu, 23 May 2013 02:27:06 -0400 Marc Delisle marc@infomarc.info napsal(a):
Your pull request targets master and I've sent comments for it. When it's ready, do you feel that this patch belongs to 4.0?
IMHO no as it requires CodeMirror upgrade. Also I currently have no idea how to incorporate links to doc as we have them in PHP highlighter, so at current state it would mean losing functionality.
If we don't use CodeMirror for highlighting in 4.0, I suggest we remove these incorrect reserved words for 4.0, even if this will break highlighting, because getting false warnings about reserved words is worse that incorrect hightlighting.
I agree.
-
Madhura Jayaratne -
Marc Delisle -
Michal Čihař -
Supun Nakandala