Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL)
Description
In the following test, the first ALTER TABLE unexpectedly fails:
--source include/have_innodb.inc
|
|
CREATE TABLE t1 (e enum('a','b','c') COLLATE utf8mb4_unicode_ci DEFAULT 'a') ENGINE=InnoDB; |
|
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
|
ALTER TABLE t1 MODIFY e ENUM('a','b','c','d'), ALGORITHM=INSTANT; |
|
ALTER TABLE t1 MODIFY e ENUM('a','b','c','d') COLLATE utf8mb4_unicode_ci, ALGORITHM=INSTANT; |
DROP TABLE t1; |
I believe that it is wrong to require that the collation matches in this case. Even if there was an index defined on the column, that index should use normal integer sorting rules, and the collation on the textual ENUM symbols that map to the integer symbols should not matter at all.
Attachments
Issue Links
- relates to
-
MDEV-11424 Instant ALTER TABLE of failure-free record format changes
- Closed
-
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes
- Closed