Hi, Please see the line 28 of [0] which is the var_dump of PMA_SQP_analyze(PMA_SQP_parse($create_query)). The 'table_ref' index is an empty array.
I think it should have name of the table to be created or current one is correct?
Because in the result there is no index which mention table name separately.
Also, at [0]#L34: 'create_table_fields' index should contain only column details if I am not wrong. But at [0]#L44, 'latin_general_ci' which is actually the collation of the table, is appearing in the middle. Is this a desired behaviour or it is a bug?
Note: The query passed is present in 'unsorted_query' index at [0]#L16.
[0]: http://pastebin.com/YcbuivPB
Le 2014-06-05 07:34, Chirayu Chiripal a écrit :
Hi, Please see the line 28 of [0] which is the var_dump of PMA_SQP_analyze(PMA_SQP_parse($create_query)). The 'table_ref' index is an empty array.
I think it should have name of the table to be created or current one is correct?
Hi Chirayu, the parser sets 'table_ref' only for SELECT statements.
Because in the result there is no index which mention table name separately.
Also, at [0]#L34: 'create_table_fields' index should contain only column details if I am not wrong. But at [0]#L44, 'latin_general_ci' which is actually the collation of the table, is appearing in the middle. Is this a desired behaviour or it is a bug?
A bug.
Note: The query passed is present in 'unsorted_query' index at [0]#L16.
On Sun, Jun 8, 2014 at 6:00 PM, Marc Delisle marc@infomarc.info wrote:
Le 2014-06-05 07:34, Chirayu Chiripal a écrit :
Hi, Please see the line 28 of [0] which is the var_dump of PMA_SQP_analyze(PMA_SQP_parse($create_query)). The 'table_ref' index is an empty array.
I think it should have name of the table to be created or current one is correct?
Hi Chirayu, the parser sets 'table_ref' only for SELECT statements.
Because in the result there is no index which mention table name
separately.
Also, at [0]#L34: 'create_table_fields' index should contain only column details if I am not wrong. But at [0]#L44, 'latin_general_ci' which is actually the collation of the table, is appearing in the middle. Is this a desired behaviour or it is a bug?
A bug.
Hi, I found the reason for the collation coming back as the column name, I did the var_dump() with ‘TESTSUITE’ defined as 1 and I noticed that when TESTSUITE is defined then mysql_charsets are not fetched and hence it is not able to detect that it is charset not a normal identifier (See https://github.com/phpmyadmin/phpmyadmin/blob/master/libraries/sqlparser.lib...) otherwise when TESTSUITE is not defined then column names are detected properly.
Note: The query passed is present in 'unsorted_query' index at [0]#L16.
-- Marc Delisle | phpMyAdmin
-
Chirayu Chiripal -
Marc Delisle