20 May
2013
20 May
'13
2:32 p.m.
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
20 May
20 May
2:45 p.m.
On Mon, May 20, 2013 at 5:02 PM, Supun Nakandala
<supun.nakandala(a)gmail.com>wrote;wrote:
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-w…
<http://stackoverflow.com/questions/16593166/is-type-and-status-a-reserved-word-in-mysql/16593413#16593413>
--
Thanks and Regards,
Madhura Jayaratne
6:55 p.m.
Madhura Jayaratne a écrit :
On Mon, May 20, 2013 at 5:02 PM, Supun Nakandala
<supun.nakandala(a)gmail.com>wrote;wrote:
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.
--
Marc Delisle
http://infomarc.info
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-w…
<http://stackoverflow.com/questions/16593166/is-type-and-status-a-reserved-word-in-mysql/16593413#16593413>
8:46 p.m.
Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)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ř | http://cihar.com | http://phpmyadmin.net
8:58 p.m.
Michal Čihař a écrit :
--
Marc Delisle
http://infomarc.info
Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
git grep reservedWord
shows a few other places to check
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...
21 May
21 May
10:17 a.m.
Hi
Dne Mon, 20 May 2013 13:58:02 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
Michal Čihař a écrit :
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?).
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
git grep reservedWord
shows a few other places to check 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 :-).
1:38 p.m.
Le 2013-05-21 03:17, Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 13:58:02 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
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.
--
Marc Delisle
http://infomarc.info
Michal Čihař a écrit :
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?). Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
git grep reservedWord
shows a few other places to check 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 :-).
2 p.m.
Le 2013-05-21 03:17, Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 13:58:02 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
Removing words like LIMIT, SELECT, UPDATE, etc from the list would cause
a problem, but these words are in the official MySQL list.
--
Marc Delisle
http://infomarc.info
Michal Čihař a écrit :
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?). Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)infomarc.info> napsal(a):
git grep reservedWord
shows a few other places to check 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 :-).
11:07 a.m.
Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)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
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
23 May
23 May
9:27 a.m.
Le 2013-05-21 04:07, Michal Čihař a écrit :
Hi
Dne Mon, 20 May 2013 11:55:26 -0400
Marc Delisle <marc(a)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?
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.
--
Marc Delisle
http://infomarc.info
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
10:30 a.m.
Hi
Dne Thu, 23 May 2013 02:27:06 -0400
Marc Delisle <marc(a)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.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
4138
days inactive
4141
days old
10 comments
4 participants
participants (4)
-
Madhura Jayaratne -
Marc Delisle -
Michal Čihař -
Supun Nakandala