Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10
-
None
Description
It appears to me that --allow-keywords in mysqldump cannot have any use. Of course it's hard to prove an absence of scenario, so I may be missing something.
From what I see, it is used in 3 places: twice interchangeably with --quote-names, to define the value for SQL_QUOTE_SHOW_CREATE (one of these occurrences seems to be ifdef-ed out); and once on its own to decide whether column names in the table definition must be prefixed with a table name, which is apparently the whole idea behind the option. But
- if --quote-names is turned on, there is no need in --allow-keywords as the identifiers will be quoted anyway;
- --allow-keywords cannot really replace --quote-names (cannot be used without it) when data is also dumped, because if a keyword is really used for a column name, without --quote-names mysqldump fails on SELECT from the table, trying to use the unquoted name;
- so, for the option to play a role, mysqldump must be run with --skip-quote-names --no-data;
- even in this case, it can only get to its target logic if SET SQL_QUOTE_SHOW_CREATE fails on whatever reason (and if mysqldump runs with --force, otherwise it will just abort);
- even if all this happens, the route it takes is apparently designed for --xml execution, and the table structure it ends up with is likely to be invalid, regardless whether it uses keywords for column names or not, e.g.:
CREATE TABLE `t` ( |
`t`.`i` int(11) DEFAULT 'NULL' |
)/*! engine=InnoDB */; |
(which further fails due to a wrong default value).
So, all in all, I can't find a scenario when it would work. If it exists, maybe we should update documentation to indicate it.