Hi, Change: Another change is that it uses the index name for the internal dictionary. Not ok. Firstly, that change should affect many test cases using foreign keys. Secondly, that would effect applications using foreign keys. I could only imagine how many and what kind of applications there are to create/drop foreign keys that are currently created with InnoDB internal foreign key names. Finally, this fix is 'correct' only for new tables, not existing tables containing foreign keys. This change would be incompatibility change to default behavior.
At file:///home/hf/wmar/10-hf/
------------------------------------------------------------ revno: 3984 revision-id: holyfoot@askmonty.org-20140205184909-9nmsj1mzwo6cka0m parent: sergii@pisem.net-20140205171851-0vax8lnwtbousucu committer: Alexey Botchkov <holyfoot@askmonty.org> branch nick: 10-hf timestamp: Wed 2014-02-05 22:49:09 +0400 message: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. Patches for server and the Innodb engine. Server is fixed so it does nothing if no indexes left to alter. Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. Another change is that it uses the index name for the internal dictionary. Prior to that it only used the CONSTRAINT name for it.
_______________________________________________ commits mailing list commits@mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits
-- -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>