Details
-
Bug
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL)
Description
--source include/have_innodb.inc
|
|
|
CREATE TEMPORARY TABLE t (a INT, KEY(a)) ENGINE=InnoDB; |
INSERT INTO t VALUES (1); |
ALTER TABLE t DROP FOREIGN KEY fk; |
|
|
# Cleanup
|
DROP TABLE t; |
|
10.3 77951dd7 |
CREATE TEMPORARY TABLE t (a INT, KEY(a)) ENGINE=InnoDB; |
INSERT INTO t VALUES (1); |
ALTER TABLE t DROP FOREIGN KEY fk; |
DROP TABLE t; |
So, although there is no foreign key fk (or any other), ALTER succeeds.
Reproducible on all current version lines of MariaDB and on MySQL 5.7. Not reproducible on MySQL 8.0.
Attachments
Activity
I do not think that temporary tables ever supported FOREIGN KEY constraints in InnoDB, not even when they were actually persistent tables (before InnoDB in MySQL 5.7 and MariaDB 10.2 stopped writing any log for them).
According to marko,
The culprit should be outside InnoDB, because ALTER TABLE on temporary tables always goes through the ALGORITHM=COPY route.
And yet, adding an invalid FK to a temporary InnoDB table causes typical "incorrectly formed" errors (unlike adding the same to a MyISAM table, which truly doesn't care). So if it's unsupported, it's inconsistently unsupported.