Details
-
New Feature
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
-
Like the names of indexes or CHECK constraints, the names of FOREIGN KEY constraints will be unique within a table. That is, from now on you can create multiple tables with CONSTRAINT fk_name FOREIGN KEY, in the same schema or database.
Description
Starting with MySQL 4.0.18, InnoDB can store user specified FOREIGN KEY constraint names. But, for no good reason, these names must be unique within a schema. Let us allow the constraint names to be unique within a table.
Furthermore, let us make the generated FOREIGN KEY constraint names be simply ASCII numbers 1, 2, 3, and so on. Previously, the user-visible generated names were tablename_ibfk_1, tablename_ibfk_2 and so on, while the internal names were like schemaname/tablename_ibfk_1. In the new scheme, the internal names that are only visible in the InnoDB system tables SYS_FOREIGN and SYS_FOREIGN_COLS are prefixed with schemaname/tablename and the impossible UTF-8 sequence 0xff. This prefix is hidden from the SQL layer.
Upgrade considerations
- Foreign key constraints will no longer be displayed as schemaname/constraintname to the users. Only the constraintname part will be displayed.
- On ALTER TABLE…ALGORITHM=COPY, all internal names of constraints will be adjusted: the schenamame/ prefix will be changed to schemaname/tablename\377.
- The user-visible part of any constraints of the form oldtablename_ibfk_1 will no longer be changed on RENAME TABLE oldtablename TO newtablename.
- The internal names will be changed, e.g. from schemaname/oldtablename_ibfk_1 to schemaname/newtablename\377oldtablename_ibfk_1.
- ALTER TABLE…DROP FOREIGN KEY will attempt to drop both old and new format constraint names.
Downgrade considerations
- Foreign key constraints are expected to work, but the error messages may display an incorrect constraint name.
- If the invalid UTF-8 sequence 0xff is being treated as a string terminator, the constraint name would not be reported as schemaname/constraintname but schemaname/tablename.
- Both DROP TABLE and DROP DATABASE will be able to drop the associated FOREIGN KEY constraints.
- This can be tested by running ./mtr --manual-gdb innodb.innodb-fk with two versions of the server.
- ALTER TABLE…DROP FOREIGN KEY will be unable to drop constraints that are in the new format, because it will be impossible to input the invalid UTF-8 sequence 0xff as part of the constraint name.
Attachments
Issue Links
- blocks
-
MDEV-19191 Partitioning in child tables with foreign keys
-
- In Review
-
-
MDEV-25292 Atomic CREATE OR REPLACE TABLE
-
- Stalled
-
- causes
-
CONCPP-143 Possible issues in getImportedKeys, getExportedKeys and getCrossReference with 12.1 server
-
- Closed
-
-
CONJ-1279 metadata table name addition for 12.1
-
- Closed
-
-
MDEV-37077 Server crashes in dict_foreign_t::sql_id upon adding a wrong FK
-
- Closed
-
-
MDEV-37592 FK naming change breaks connector compatibility - revert default names from '1' to '<table>_ibfk_1'
-
- Closed
-
- is blocked by
-
MDEV-28980 InnoDB: Failing assertion: len <= MAX_TABLE_NAME_LEN
-
- Closed
-
- relates to
-
MDEV-29409 ASAN failure on long fk_id when renaming a table
-
- Closed
-
-
MDEV-20865
Store foreign key info in FRM and TABLE_SHARE
-
- In Review
-
-
MDEV-29258 Failing assertion for name length on RENAME TABLE
-
- Closed
-
-
MDEV-30416 Can't redefine constraint in a single ALTER TABLE
-
- Confirmed
-
-
MDEV-36540 Assertion `!tdc_share_is_cached(thd, db->str, table->str)' fails in execute_drop_table
-
- Open
-