Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.11.1, 10.6.12, 10.8.7, 10.9.5, 10.10.3, 10.7(EOL)
Description
When creating a foreign key constraint the referenced columns on both sides need to have the same data types, including same character set. E.g.
CREATE TABLE t1(
|
id SERIAL,
|
msg VARCHAR(100) CHARACTER SET utf8mb3,
|
KEY(msg)
|
);
|
 |
CREATE TABLE t2(
|
id SERIAL,
|
msg varchar(100) CHARACTER SET utf8mb4,
|
CONSTRAINT fk_t1 FOREIGN KEY (msg) REFERENCES t1 (msg)
|
);
|
will fail with "Foreign key constraint is incorrectly formed" due to the mix of utf8mb3 and utf8mb4. Even with foreign_key_checks=OFF this will still not work.
Changing the character set to "utf8mb3" I can create the 2nd table now, as expected:
CREATE TABLE t2(
|
id SERIAL,
|
msg varchar(100) CHARACTER SET utf8mb3,
|
CONSTRAINT fk_t1 FOREIGN KEY (msg) REFERENCES t1 (msg)
|
);
|
Now the problem is that starting with 10.6 I can change the character set "under the hood" without getting an error at all, regardless of foreign_key_checks being ON or OFF:
ALTER TABLE t2
|
MODIFY COLUMN msg VARCHAR(100) CHARACTER SET utf8mb4;
|
With 10.5 and earlier the situation is a bit better, the MODIFY COLUMN will lead to
Cannot change column 'msg': used in a foreign key constraint 'fk_t1'
when foreign_key_checks are ON, but will succeed when checks are OFF; unlike the CREATE TABLE above that will fail regardless of checks being ON or OFF.
And with that we now have a table with a broken foreign key constraint, and a schema that we can dump with mysqldump, but not restore as the dump now contains a CREATE TABLE statement with a FK CONSTRAINT that will lead to an
Foreign key constraint is incorrectly formed
error even though mysqldump takes care to turn off foreign_key_checks for the duration of a restore.
So two things need to be fixed here IMHO:
- on 10.6 or later: MODIFY TABLE definitely needs to fail if foreign_key_checks are ON
- on all versions: with CREATE TABLE not allowing to create a FK constraint with column type mismatches regardless of foreign_key_checks, MODIFY COLUMN should not allow for this even with checks turned OFF either; or both should allow this when checks are OFF, for symmetry reasons
Attachments
Issue Links
- causes
-
MDEV-31869 Server aborts when table does drop column
- Closed
-
MDEV-31987 Cannot disable FOREIGN_KEY_CHECKS anymore for converting character set
- Closed
-
MDEV-32003 MODIFY COLUMN no longer possible with Foreign Key Constraints
- Closed
-
MDEV-32018 Allow the setting of Auto_increment on FK referenced columns
- Closed
-
MDEV-32060 Server crashes in check_col_is_in_fk_indexes upon non-copying column modification
- Closed
-
MDEV-32337 Assertion `pos < table->n_def' failed in dict_table_get_nth_col
- Closed
-
MDEV-32527 Server aborts during alter operation when table doesn't have foreign index
- Closed
-
MDEV-32638 MariaDB crashes with foreign_key_checks=0 when changing a column and adding a foreign key at the same time
- Closed
-
MDEV-34392 modification of the column fails to check foreign key constraint
- Closed
- duplicates
-
MDEV-24680 Unexpected behavior with foreign keys or InnoDB: Failing assertion: cmp < 0
- Closed
-
MDEV-25619 Bogus ER_TABLE_EXISTS_ERROR upon an attempt to add a foreign key
- Closed
- relates to
-
MDEV-32171 When updating cascaded foreign keys, closing foreign key constraints is ignored and invalid.
- Closed
-
MDEV-34110 FK Constraint not dropped but modify succesfull
- Confirmed
-
MDEV-25620 InnoDB: Failing assertion: id != 0 or Assertion `dict_table_is_file_per_table(this)' failed in dict_table_t::rename_tablespace
- Closed
-
MDEV-32729 look at SET FOREIGN_KEY_CHECK=0
- Closed