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

Twitter Blog Facebook LinkedIn Google+