Version information: 4.3.3 (up to date)
Git revision: 953e3e0 from STABLE branch,
committed on Dec 21, 2014 at 02:41 AM by Marc Delisle
Server type: MySQL
Server version: 5.6.21 - Homebrew
Protocol version: 10
Apache
Database client version: libmysql - mysqlnd 5.0.11-dev - 20120503 - $Id: f373ea5dd5538761406a8022a4b8a374418b240e $
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No i expect that if the output backquote reserved words for create table statements that it will also do so for alter table statements. Even with "Enclose table and column names with backquotes" off.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should say it this way. Currently with "Enclose table and column names with backquotes" off it will still backquote reserved words in the create table statement but not the alter table statement. So ether one or the other is a bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Depends on the aim of the exporter. I didn't want every thing to be backquoted but since I am using a reserved word for a table name it has to be. So my preference would be to still backquote all reserved words because otherwise you sql export will not work.
Another thing to note is that even for CREATE TABLE statements it will only backquote reserved words. Which is what I wanted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
If i understand it correctly , for table name with reserved word ,the table name should be backquoted both in "create table .." as well as "alter table .." statements even if the user has custom uncheck "Enclose table and column names with backquotes" ? as if we don't backquote the reserved word table name , it will be an issue while importing it back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Version information: 4.3.3 (up to date)
Git revision: 953e3e0 from STABLE branch,
committed on Dec 21, 2014 at 02:41 AM by Marc Delisle
Server type: MySQL
Server version: 5.6.21 - Homebrew
Protocol version: 10
Apache
Database client version: libmysql - mysqlnd 5.0.11-dev - 20120503 - $Id: f373ea5dd5538761406a8022a4b8a374418b240e $
Cannot reproduce in 4.3.3; please attach a small export showing the problem.
I just did a little more digging. Create a table with this
Then do an export but under custom uncheck "Enclose table and column names with backquotes" Then the export looks like this
Last edit: Brandon S 2014-12-22
So, you are wondering why there are no backquotes, when you have asked to not put backquotes in the export file?
No i expect that if the output backquote reserved words for create table statements that it will also do so for alter table statements. Even with "Enclose table and column names with backquotes" off.
I should say it this way. Currently with "Enclose table and column names with backquotes" off it will still backquote reserved words in the create table statement but not the alter table statement. So ether one or the other is a bug.
So the bug's title should be "Deactivating backquotes in export does not work in CREATE TABLE", right?
Depends on the aim of the exporter. I didn't want every thing to be backquoted but since I am using a reserved word for a table name it has to be. So my preference would be to still backquote all reserved words because otherwise you sql export will not work.
Another thing to note is that even for CREATE TABLE statements it will only backquote reserved words. Which is what I wanted.
Hi,
If i understand it correctly , for table name with reserved word ,the table name should be backquoted both in "create table .." as well as "alter table .." statements even if the user has custom uncheck "Enclose table and column names with backquotes" ? as if we don't backquote the reserved word table name , it will be an issue while importing it back.
PR https://github.com/phpmyadmin/phpmyadmin/pull/1435/
Rakesh,
Yes, what you are saying is correct.