I had mental slippage one day and added a column called "status" after an existing column... I also added another column after my newly created "status" column...
The alters looked like this:
ALTER TABLE transport ADD COLUMN status VARCHAR(3) DEFAULT NULL AFTER dos;
ALTER TABLE transport ADD COLUMN invoice VARCHAR(3) DEFAULT NULL AFTER status;
Both of these statements, rather than throwing an error prior to execution, tried to execute and left me with an orphaned transport.ibd file and 3 #sql- files.
Repairing was not possible using any of the techniques provided in the documentation.
This was in my testing area, so nothing made it out into production. It just caused me to have to start over with mysql_install_db and reload all the mysqldump files... Twice, since I missed correcting the second ALTER in my scripts. (ouch!)
My testing area is using MySQL 5.5.40 on Ubuntu 14.04.1 TLS.
Would it not be a good idea to throw an error when a reserved word is encountered vs. trashing the Innodb table information structures?
The alters looked like this:
ALTER TABLE transport ADD COLUMN status VARCHAR(3) DEFAULT NULL AFTER dos;
ALTER TABLE transport ADD COLUMN invoice VARCHAR(3) DEFAULT NULL AFTER status;
Both of these statements, rather than throwing an error prior to execution, tried to execute and left me with an orphaned transport.ibd file and 3 #sql- files.
Repairing was not possible using any of the techniques provided in the documentation.
This was in my testing area, so nothing made it out into production. It just caused me to have to start over with mysql_install_db and reload all the mysqldump files... Twice, since I missed correcting the second ALTER in my scripts. (ouch!)
My testing area is using MySQL 5.5.40 on Ubuntu 14.04.1 TLS.
Would it not be a good idea to throw an error when a reserved word is encountered vs. trashing the Innodb table information structures?