mariadb/mysql-test/suite/innodb/t/instant_alter_charset.test

891 lines
31 KiB
Text
Raw Normal View History

MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
--source include/innodb_row_format.inc
--let $row_format= `SELECT @@GLOBAL.innodb_default_row_format`
set names utf8;
create table no_rebuild (
a char(150) charset utf8mb3 collate utf8mb3_general_ci
) engine=innodb;
create table rebuild (
a varchar(150) charset ascii
) engine=innodb;
set @id = (select table_id from information_schema.innodb_sys_tables
where name = 'test/no_rebuild');
select name, prtype, len from information_schema.innodb_sys_columns
where table_id = @id;
select c.prtype, c.len from information_schema.innodb_sys_columns as c inner join information_schema.innodb_sys_tables t on c.table_id = t.table_id
where t.name = 'test/rebuild' and c.name = 'a';
alter table no_rebuild
change a a char(150) charset utf8mb3 collate utf8mb3_spanish_ci,
algorithm=inplace;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
alter table rebuild
change a a varchar(150) charset latin1 not null default 'asdf',
algorithm=inplace;
alter table rebuild
change a a varchar(150) charset latin1 not null default 'asdf',
algorithm=copy;
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
select name, prtype, len from information_schema.innodb_sys_columns
where table_id = @id;
select c.prtype, c.len from information_schema.innodb_sys_columns as c inner join information_schema.innodb_sys_tables t on c.table_id = t.table_id
where t.name = 'test/rebuild' and c.name = 'a';
drop table no_rebuild, rebuild;
create table supported_types (
id int primary key auto_increment,
a varchar(150) charset ascii,
b text(150) charset ascii,
c text charset ascii,
d tinytext charset ascii,
e mediumtext charset ascii,
f longtext charset ascii
) engine=innodb;
alter table supported_types
convert to charset ascii collate ascii_bin,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=instant;
drop table supported_types;
create table various_cases (
a char(150) charset ascii,
b varchar(150) as (a) virtual,
2019-09-06 11:53:10 +02:00
c char(150) as (a) persistent
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
) engine=innodb;
alter table various_cases
change a a char(150) charset ascii collate ascii_bin,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=inplace;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table various_cases
change a a varchar(222),
algorithm=inplace;
alter table various_cases
change b b varchar(150) as (a) virtual,
algorithm=inplace;
--error ER_ALTER_OPERATION_NOT_SUPPORTED
alter table various_cases
2019-09-06 11:53:10 +02:00
change c c char(150) as (a) persistent,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=inplace;
# Can not grow storage in bytes from CHAR
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table various_cases
modify a char(150) charset utf8mb4,
algorithm=instant;
drop table various_cases;
create table all_texts (
a tinytext charset ascii,
b text charset ascii,
c mediumtext charset ascii,
d longtext charset ascii,
footer int
) engine=innodb;
alter table all_texts
convert to charset ascii collate ascii_bin,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=instant;
drop table all_texts;
create table all_binaries (
a tinyblob,
b blob,
c mediumblob,
d longblob,
e varbinary(150),
f binary(150)
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_binaries modify a tinytext, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_binaries modify b text, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_binaries modify c mediumtext, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_binaries modify d longtext, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_binaries modify e varchar(150), algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_binaries modify f char(150), algorithm=instant;
drop table all_binaries;
create table all_strings (
a tinytext,
b text,
c mediumtext,
d longtext,
e varchar(150),
f char(150)
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify a tinyblob, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify b blob, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify c mediumblob, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify d longblob, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify e varbinary(150), algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify f binary(150), algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify a tinytext charset binary, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify b text charset binary, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify c mediumtext charset binary, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify d longtext charset binary, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify e varchar(150) charset binary, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table all_strings modify f char(150) charset binary, algorithm=instant;
drop table all_strings;
create table key_part_change (
a char(150) charset ascii,
b char(150) charset ascii,
c char(150) charset ascii,
unique key ab (a,b)
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table key_part_change
modify a char(150) charset utf8mb4,
drop index ab,
add unique key ab(a,c),
algorithm=instant;
drop table key_part_change;
create table key_part_change_and_rename (
a char(100) charset ascii,
b char(100) charset ascii,
unique key ab (a,b)
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table key_part_change_and_rename
change a b char(100) charset utf8mb4,
change b a char(100) charset utf8mb4,
drop index ab,
add unique key ab(a,b),
algorithm=instant;
drop table key_part_change_and_rename;
create table enum_and_set (
a enum('one', 'two') charset utf8mb3,
b set('three', 'four') charset utf8mb3
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table enum_and_set
modify a enum('one', 'two') charset utf8mb4,
algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table enum_and_set
modify b enum('three', 'four') charset utf8mb4,
algorithm=instant;
drop table enum_and_set;
create table compressed (
2019-06-19 10:49:00 +03:00
a varchar(255) compressed charset utf8mb3
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
) engine=innodb;
insert into compressed values ('AAA'), ('bbb'), ('CCC');
alter table compressed
2019-06-19 10:49:00 +03:00
modify a varchar(255) compressed charset utf8mb4,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=instant;
select * from compressed;
check table compresed;
drop table compressed;
create table key_part_bug (
id int primary key auto_increment,
a varchar(150) charset utf8mb3 unique key
) engine=innodb;
alter table key_part_bug
modify a varchar(150) charset utf8mb4,
algorithm=instant;
drop table key_part_bug;
create table latin1_swedish_special_case (
copy1 varchar(150) charset ascii collate ascii_general_ci,
copy2 char(150) charset ascii collate ascii_general_ci,
instant1 varchar(150) charset ascii collate ascii_general_ci,
instant2 char(150) charset ascii collate ascii_general_ci
) engine=innodb;
select c.name, c.prtype, c.mtype, c.len from information_schema.innodb_sys_columns as c inner join information_schema.innodb_sys_tables t on c.table_id = t.table_id
where t.name = 'test/latin1_swedish_special_case';
alter table latin1_swedish_special_case
modify copy1 varchar(150) charset latin1 collate latin1_swedish_ci,
modify copy2 char(150) charset latin1 collate latin1_swedish_ci,
algorithm=copy;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
alter table latin1_swedish_special_case
modify instant1 varchar(150) charset latin1 collate latin1_swedish_ci,
modify instant2 char(150) charset latin1 collate latin1_swedish_ci,
algorithm=instant;
alter table latin1_swedish_special_case
modify instant1 varchar(150) charset latin1 collate latin1_swedish_ci,
modify instant2 char(150) charset latin1 collate latin1_swedish_ci,
algorithm=copy;
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
select c.name, c.prtype, c.mtype, c.len from information_schema.innodb_sys_columns as c inner join information_schema.innodb_sys_tables t on c.table_id = t.table_id
where t.name = 'test/latin1_swedish_special_case';
alter table latin1_swedish_special_case
modify copy1 varchar(150) charset latin1 collate latin1_general_ci,
modify copy2 char(150) charset latin1 collate latin1_general_ci,
algorithm=copy;
alter table latin1_swedish_special_case
modify instant1 varchar(150) charset latin1 collate latin1_general_ci,
modify instant2 char(150) charset latin1 collate latin1_general_ci,
algorithm=instant;
select c.name, c.prtype, c.mtype, c.len from information_schema.innodb_sys_columns as c inner join information_schema.innodb_sys_tables t on c.table_id = t.table_id
where t.name = 'test/latin1_swedish_special_case';
drop table latin1_swedish_special_case;
create table regression (a varchar(100) charset utf8mb3 primary key, b int) engine=innodb;
alter table regression convert to character set utf8mb4;
drop table regression;
# ROW_FORMAT=DYNAMIC limitation:
# size in bytes cannot be increased from less of equal that 255 to more than 255
create table boundary_255 (
a varchar(50) charset ascii,
b varchar(200) charset ascii,
c varchar(300) charset ascii
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
alter table boundary_255
modify a varchar(50) charset utf8mb3,
algorithm=instant;
alter table boundary_255
modify a varchar(50) charset utf8mb3,
algorithm=copy;
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
alter table boundary_255
modify b varchar(200) charset utf8mb3,
algorithm=instant;
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table boundary_255
modify c varchar(300) charset utf8mb3,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=instant;
drop table boundary_255;
create table boundary_255 (
a varchar(70) charset utf8mb3
) engine=innodb;
if ($row_format == 'redundant') {
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
alter table boundary_255
modify a varchar(70) charset utf8mb4,
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
algorithm=instant;
}
if ($row_format != 'redundant') {
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table boundary_255
modify a varchar(70) charset utf8mb4,
algorithm=instant;
}
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
drop table boundary_255;
create table t (
a char(10) collate utf8mb3_general_ci,
b char(70) collate utf8mb3_general_ci,
c char(100) collate utf8mb3_general_ci,
aa char(10) collate utf8mb3_general_ci unique,
bb char(70) collate utf8mb3_general_ci unique,
cc char(100) collate utf8mb3_general_ci unique,
d char(10) collate utf8mb3_general_ci,
dd char(10) collate utf8mb3_general_ci unique
) engine=innodb;
insert into t values
(repeat('a', 10), repeat('a', 70), repeat('a', 100),
repeat('a', 10), repeat('a', 70), repeat('a', 100),
repeat('a', 10), repeat('a', 10)
);
if ($row_format != 'redundant') {
alter table t modify a char(10) collate utf8mb4_general_ci, algorithm=instant;
check table t;
alter table t modify b char(70) collate utf8mb4_general_ci, algorithm=instant;
check table t;
alter table t modify c char(100) collate utf8mb4_general_ci, algorithm=instant;
check table t;
alter table t modify aa char(10) collate utf8mb4_general_ci, algorithm=instant;
check table t;
alter table t modify bb char(70) collate utf8mb4_general_ci, algorithm=instant;
check table t;
alter table t modify cc char(100) collate utf8mb4_general_ci, algorithm=instant;
check table t;
alter table t modify d char(10) collate utf8mb4_spanish_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify dd char(10) collate utf8mb4_spanish_ci, algorithm=instant;
}
if ($row_format == 'redundant') {
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify a char(10) collate utf8mb4_general_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify b char(70) collate utf8mb4_general_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify c char(100) collate utf8mb4_general_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify aa char(10) collate utf8mb4_general_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify bb char(70) collate utf8mb4_general_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify cc char(100) collate utf8mb4_general_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify d char(10) collate utf8mb4_spanish_ci, algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify dd char(10) collate utf8mb4_spanish_ci, algorithm=instant;
}
select * from t;
drop table t;
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
create table fully_compatible (
id int auto_increment unique key,
from_charset char(255),
from_collate char(255),
to_charset char(255),
to_collate char(255)
);
insert into fully_compatible (from_charset, from_collate, to_charset, to_collate) values
('utf8mb3', 'utf8mb3_general_ci', 'utf8mb4', 'utf8mb4_general_ci'),
('utf8mb3', 'utf8mb3_bin', 'utf8mb4', 'utf8mb4_bin'),
('utf8mb3', 'utf8mb3_unicode_ci', 'utf8mb4', 'utf8mb4_unicode_ci'),
('utf8mb3', 'utf8mb3_icelandic_ci', 'utf8mb4', 'utf8mb4_icelandic_ci'),
('utf8mb3', 'utf8mb3_latvian_ci', 'utf8mb4', 'utf8mb4_latvian_ci'),
('utf8mb3', 'utf8mb3_romanian_ci', 'utf8mb4', 'utf8mb4_romanian_ci'),
('utf8mb3', 'utf8mb3_slovenian_ci', 'utf8mb4', 'utf8mb4_slovenian_ci'),
('utf8mb3', 'utf8mb3_polish_ci', 'utf8mb4', 'utf8mb4_polish_ci'),
('utf8mb3', 'utf8mb3_estonian_ci', 'utf8mb4', 'utf8mb4_estonian_ci'),
('utf8mb3', 'utf8mb3_spanish_ci', 'utf8mb4', 'utf8mb4_spanish_ci'),
('utf8mb3', 'utf8mb3_swedish_ci', 'utf8mb4', 'utf8mb4_swedish_ci'),
('utf8mb3', 'utf8mb3_turkish_ci', 'utf8mb4', 'utf8mb4_turkish_ci'),
('utf8mb3', 'utf8mb3_czech_ci', 'utf8mb4', 'utf8mb4_czech_ci'),
('utf8mb3', 'utf8mb3_danish_ci', 'utf8mb4', 'utf8mb4_danish_ci'),
('utf8mb3', 'utf8mb3_lithuanian_ci', 'utf8mb4', 'utf8mb4_lithuanian_ci'),
('utf8mb3', 'utf8mb3_slovak_ci', 'utf8mb4', 'utf8mb4_slovak_ci'),
('utf8mb3', 'utf8mb3_spanish2_ci', 'utf8mb4', 'utf8mb4_spanish2_ci'),
('utf8mb3', 'utf8mb3_roman_ci', 'utf8mb4', 'utf8mb4_roman_ci'),
('utf8mb3', 'utf8mb3_persian_ci', 'utf8mb4', 'utf8mb4_persian_ci'),
('utf8mb3', 'utf8mb3_esperanto_ci', 'utf8mb4', 'utf8mb4_esperanto_ci'),
('utf8mb3', 'utf8mb3_hungarian_ci', 'utf8mb4', 'utf8mb4_hungarian_ci'),
('utf8mb3', 'utf8mb3_sinhala_ci', 'utf8mb4', 'utf8mb4_sinhala_ci'),
('utf8mb3', 'utf8mb3_german2_ci', 'utf8mb4', 'utf8mb4_german2_ci'),
('utf8mb3', 'utf8mb3_croatian_mysql561_ci', 'utf8mb4', 'utf8mb4_croatian_mysql561_ci'),
('utf8mb3', 'utf8mb3_unicode_520_ci', 'utf8mb4', 'utf8mb4_unicode_520_ci'),
('utf8mb3', 'utf8mb3_vietnamese_ci', 'utf8mb4', 'utf8mb4_vietnamese_ci'),
('utf8mb3', 'utf8mb3_croatian_ci', 'utf8mb4', 'utf8mb4_croatian_ci'),
('utf8mb3', 'utf8mb3_myanmar_ci', 'utf8mb4', 'utf8mb4_myanmar_ci'),
('utf8mb3', 'utf8mb3_thai_520_w2', 'utf8mb4', 'utf8mb4_thai_520_w2'),
('utf8mb3', 'utf8mb3_general_nopad_ci', 'utf8mb4', 'utf8mb4_general_nopad_ci'),
('utf8mb3', 'utf8mb3_nopad_bin', 'utf8mb4', 'utf8mb4_nopad_bin'),
('utf8mb3', 'utf8mb3_unicode_nopad_ci', 'utf8mb4', 'utf8mb4_unicode_nopad_ci'),
('utf8mb3', 'utf8mb3_unicode_520_nopad_ci', 'utf8mb4', 'utf8mb4_unicode_520_nopad_ci')
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
;
let $data_size = `select count(*) from fully_compatible`;
let $counter = 1;
while ($counter <= $data_size) {
let $from_charset = `select from_charset from fully_compatible where id = $counter`;
let $from_collate = `select from_collate from fully_compatible where id = $counter`;
let $to_charset = `select to_charset from fully_compatible where id = $counter`;
let $to_collate = `select to_collate from fully_compatible where id = $counter`;
eval create table tmp (
a varchar(50) charset $from_charset collate $from_collate,
b varchar(50) charset $from_charset collate $from_collate primary key
) engine=innodb;
insert into tmp values ('AAA', 'AAA'), ('bbb', 'bbb');
eval alter table tmp
change a a varchar(50) charset $to_charset collate $to_collate,
modify b varchar(50) charset $to_charset collate $to_collate,
algorithm=instant;
check table tmp;
drop table tmp;
inc $counter;
}
drop table fully_compatible;
create table compatible_without_index (
id int auto_increment unique key,
from_charset char(255),
from_collate char(255),
to_charset char(255),
to_collate char(255)
);
insert into compatible_without_index (from_charset, from_collate, to_charset, to_collate) values
('utf8mb3', 'utf8mb3_general_ci', 'utf8mb4', 'utf8mb4_vietnamese_ci'),
('utf8mb3', 'utf8mb3_bin', 'utf8mb4', 'utf8mb4_vietnamese_ci'),
('utf8mb3', 'utf8mb3_general_nopad_ci', 'utf8mb4', 'utf8mb4_vietnamese_ci'),
('utf8mb3', 'utf8mb3_nopad_bin', 'utf8mb4', 'utf8mb4_vietnamese_ci'),
('ascii', 'ascii_general_ci', 'ascii', 'ascii_bin'),
('utf8mb3', 'utf8mb3_roman_ci', 'utf8mb3', 'utf8mb3_lithuanian_ci'),
('utf8mb4', 'utf8mb4_thai_520_w2', 'utf8mb4', 'utf8mb4_persian_ci'),
('utf8mb3', 'utf8mb3_myanmar_ci', 'utf8mb4', 'utf8mb4_german2_ci'),
('utf8mb3', 'utf8mb3_general_ci', 'utf8mb3', 'utf8mb3_unicode_ci'),
('latin1', 'latin1_general_cs', 'latin1', 'latin1_general_ci'),
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
('utf16', 'utf16_general_ci', 'utf16', 'utf16_german2_ci')
;
let $data_size = `select count(*) from compatible_without_index`;
let $counter = 1;
while ($counter <= $data_size) {
let $from_charset = `select from_charset from compatible_without_index where id = $counter`;
let $from_collate = `select from_collate from compatible_without_index where id = $counter`;
let $to_charset = `select to_charset from compatible_without_index where id = $counter`;
let $to_collate = `select to_collate from compatible_without_index where id = $counter`;
eval create table tmp (
a varchar(50) charset $from_charset collate $from_collate,
b varchar(50) charset $from_charset collate $from_collate unique key,
c varchar(50) charset $from_charset collate $from_collate primary key
) engine=innodb;
eval alter table tmp
change a a varchar(50) charset $to_charset collate $to_collate,
algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
eval alter table tmp
modify b varchar(50) charset $to_charset collate $to_collate,
algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
eval alter table tmp
modify c varchar(50) charset $to_charset collate $to_collate,
algorithm=instant;
drop table tmp;
inc $counter;
}
drop table compatible_without_index;
create table fully_incompatible (
id int auto_increment unique key,
from_charset char(255),
from_collate char(255),
to_charset char(255),
to_collate char(255)
);
insert into fully_incompatible (from_charset, from_collate, to_charset, to_collate) values
('ascii', 'ascii_general_ci', 'utf8mb3', 'utf8mb3_general_ci'),
('ascii', 'ascii_general_ci', 'utf8mb4', 'utf8mb4_general_ci'),
('ascii', 'ascii_general_ci', 'latin1', 'latin1_general_ci'),
('ascii', 'ascii_bin', 'latin1', 'latin1_bin'),
('ascii', 'ascii_nopad_bin', 'latin1', 'latin1_nopad_bin'),
('ascii', 'ascii_general_ci', 'latin2', 'latin2_general_ci'),
('ascii', 'ascii_general_ci', 'latin7', 'latin7_general_ci'),
('ascii', 'ascii_bin', 'koi8u', 'koi8u_bin'),
('ascii', 'ascii_bin', 'ujis', 'ujis_bin'),
('ascii', 'ascii_bin', 'big5', 'big5_bin'),
('ascii', 'ascii_bin', 'gbk', 'gbk_bin'),
('ascii', 'ascii_general_ci', 'utf8mb3', 'utf8mb3_swedish_ci'),
('ascii', 'ascii_bin', 'latin1', 'latin1_swedish_ci'),
('ascii', 'ascii_general_nopad_ci', 'latin1', 'latin1_swedish_ci'),
('ascii', 'ascii_nopad_bin', 'latin1', 'latin1_swedish_ci'),
('ascii', 'ascii_general_ci', 'koi8u', 'koi8u_bin'),
('ascii', 'ascii_general_nopad_ci', 'koi8u', 'koi8u_bin'),
('ascii', 'ascii_nopad_bin', 'koi8u', 'koi8u_bin'),
('ascii', 'ascii_general_ci', 'latin1', 'latin1_swedish_ci'),
('ascii', 'ascii_bin', 'utf8mb3', 'utf8mb3_swedish_ci'),
('ascii', 'ascii_general_nopad_ci', 'utf8mb3', 'utf8mb3_swedish_ci'),
('ascii', 'ascii_nopad_bin', 'utf8mb3', 'utf8mb3_swedish_ci'),
('ascii', 'ascii_general_ci', 'utf8mb4', 'utf8mb4_danish_ci'),
('ascii', 'ascii_bin', 'utf8mb4', 'utf8mb4_danish_ci'),
('ascii', 'ascii_general_nopad_ci', 'utf8mb4', 'utf8mb4_danish_ci'),
('ascii', 'ascii_nopad_bin', 'utf8mb4', 'utf8mb4_danish_ci'),
('ascii', 'ascii_general_ci', 'gbk', 'gbk_chinese_ci'),
('ascii', 'ascii_general_ci', 'gbk', 'gbk_chinese_nopad_ci'),
('ascii', 'ascii_general_ci', 'ujis', 'ujis_japanese_ci'),
('ascii', 'ascii_general_ci', 'big5', 'big5_chinese_ci'),
('ascii', 'ascii_general_ci', 'latin2', 'latin2_croatian_ci'),
('ascii', 'ascii_general_ci', 'latin7', 'latin7_estonian_cs'),
('ucs2', 'ucs2_general_ci', 'utf16', 'utf16_general_ci'),
('ucs2', 'ucs2_unicode_ci', 'utf16', 'utf16_unicode_ci'),
('ucs2', 'ucs2_icelandic_ci', 'utf16', 'utf16_icelandic_ci'),
('ucs2', 'ucs2_latvian_ci', 'utf16', 'utf16_latvian_ci'),
('ucs2', 'ucs2_romanian_ci', 'utf16', 'utf16_romanian_ci'),
('ucs2', 'ucs2_slovenian_ci', 'utf16', 'utf16_slovenian_ci'),
('ucs2', 'ucs2_polish_ci', 'utf16', 'utf16_polish_ci'),
('ucs2', 'ucs2_estonian_ci', 'utf16', 'utf16_estonian_ci'),
('ucs2', 'ucs2_spanish_ci', 'utf16', 'utf16_spanish_ci'),
('ucs2', 'ucs2_general_ci', 'utf16', 'utf16_general_ci'),
('ucs2', 'ucs2_myanmar_ci', 'utf16', 'utf16_thai_520_w2'),
('ucs2', 'ucs2_general_ci', 'utf16', 'utf16_unicode_nopad_ci'),
('ucs2', 'ucs2_general_mysql500_ci', 'utf16', 'utf16_spanish2_ci'),
MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes Allow ALGORITHM=INSTANT (or avoid touching any data) when changing the collation, or in some cases, the character set, of a non-indexed CHAR or VARCHAR column. There is no penalty for subsequent DDL or DML operations, and compatibility with older MariaDB versions will be unaffected. Character sets may be changed when the old encoding is compatible with the new one. For example, changing from ASCII to anything ASCII-based, or from 3-byte to 4-byte UTF-8 can sometimes be performed instantly. This is joint work with Eugene Kosov. The test cases as well as ALTER_CONVERT_TO, charsets_are_compatible(), Type_handler::Charsets_are_compatible() are his work. The Field_str::is_equal(), Field_varstring::is_equal() and the InnoDB changes were mostly rewritten by me due to conflicts with MDEV-15563. Limitations: Changes of indexed columns will still require ALGORITHM=COPY. We should allow ALGORITHM=NOCOPY and allow the indexes to be rebuilt inside the storage engine, without copying the entire table. Instant column size changes (in bytes) are not supported by all storage engines. Instant CHAR column changes are only allowed for InnoDB ROW_FORMAT=REDUNDANT. We could allow this for InnoDB when the CHAR internally uses a variable-length encoding, say, when converting from 3-byte UTF-8 to 4-byte UTF-8. Instant VARCHAR column changes are allowed for InnoDB ROW_FORMAT=REDUNDANT, and for others only if the size in bytes does not change from 128..255 bytes to more than 256 bytes. Inside InnoDB, this slightly changes the way how MDEV-15563 works and fixes the result of the innodb.instant_alter_extend test. We change the way how ALTER_COLUMN_EQUAL_PACK_LENGTH_EXT is handled. All column extension, type changes and renaming now go through a common route, except when ctx->is_instant() is in effect, for example, instant ADD or DROP COLUMN has been initiated. Only in that case we will go through innobase_instant_try() and rewrite all column metadata. get_type(field, prtype, mtype, len): Convert a SQL data type into InnoDB column metadata. innobase_rename_column_try(): Remove the update of SYS_COLUMNS. innobase_rename_or_enlarge_column_try(): New function, replacing part of innobase_rename_column_try() and all of innobase_enlarge_column_try(). Also changes column types. innobase_rename_or_enlarge_columns_cache(): Also change the column type.
2019-02-14 20:17:14 +02:00
('utf8mb4', 'utf8mb4_general_ci', 'utf8mb3', 'utf8mb3_general_ci'),
('utf8mb4', 'utf8mb4_general_ci', 'ascii', 'ascii_general_ci'),
('utf8mb3', 'utf8mb3_general_ci', 'ascii', 'ascii_general_ci'),
('utf8mb3', 'utf8mb3_general_ci', 'latin1', 'latin1_general_ci'),
('utf16', 'utf16_general_ci', 'utf32', 'utf32_general_ci'),
('latin1', 'latin1_general_ci', 'ascii', 'ascii_general_ci'),
('ascii', 'ascii_general_ci', 'swe7', 'swe7_swedish_ci'),
('eucjpms', 'eucjpms_japanese_nopad_ci', 'geostd8', 'geostd8_general_ci'),
('latin1', 'latin1_general_ci', 'utf16', 'utf16_general_ci')
;
let $data_size = `select count(*) from fully_incompatible`;
let $counter = 1;
while ($counter <= $data_size) {
let $from_charset = `select from_charset from fully_incompatible where id = $counter`;
let $from_collate = `select from_collate from fully_incompatible where id = $counter`;
let $to_charset = `select to_charset from fully_incompatible where id = $counter`;
let $to_collate = `select to_collate from fully_incompatible where id = $counter`;
eval create table tmp (
a varchar(150) charset $from_charset collate $from_collate,
b text(150) charset $from_charset collate $from_collate,
unique key b_idx (b(150))
) engine=innodb;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
eval alter table tmp
change a a varchar(150) charset $to_charset collate $to_collate,
algorithm=instant;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
eval alter table tmp
modify b text charset $to_charset collate $to_collate,
algorithm=instant;
drop table tmp;
inc $counter;
}
drop table fully_incompatible;
--echo #
--echo # MDEV-19284 INSTANT ALTER with ucs2-to-utf16 conversion produces bad data
--echo #
CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET ucs2, PRIMARY KEY(a)) ENGINE=InnoDB;
INSERT INTO t1 VALUES ('a'),(0xD800);
--error ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
ALTER TABLE t1 ALGORITHM=COPY, MODIFY a VARCHAR(10) CHARACTER SET utf16;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
ALTER TABLE t1 ALGORITHM=INSTANT, MODIFY a VARCHAR(10) CHARACTER SET utf16;
--enable_info ONCE
ALTER IGNORE TABLE t1 MODIFY a VARCHAR(10) CHARACTER SET utf16;
SELECT HEX(a) FROM t1;
DROP TABLE t1;
--echo #
--echo # MDEV-19285 INSTANT ALTER from ascii_general_ci to latin1_general_ci produces corrupt data
--echo #
CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET ascii COLLATE ascii_general_ci, PRIMARY KEY(a)) ENGINE=InnoDB;
INSERT INTO t1 VALUES ('a'),(0xC0),('b');
--error ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
ALTER TABLE t1 ALGORITHM=COPY, MODIFY a VARCHAR(10) CHARACTER SET latin1 COLLATE latin1_general_ci;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
ALTER TABLE t1 ALGORITHM=INSTANT, MODIFY a VARCHAR(10) CHARACTER SET latin1 COLLATE latin1_general_ci;
--enable_info ONCE
ALTER IGNORE TABLE t1 MODIFY a VARCHAR(10) CHARACTER SET latin1 COLLATE latin1_general_ci;
SELECT HEX(a) FROM t1;
DROP TABLE t1;
--echo #
--echo # MDEV-19524 Server crashes in Bitmap<64u>::is_clear_all / Field_longstr::csinfo_change_allows_instant_alter
--echo #
CREATE TABLE t1 (a VARCHAR(1), UNIQUE(a)) ENGINE=InnoDB;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
ALTER TABLE t1 MODIFY a INT, ADD b INT, ADD UNIQUE (b), ALGORITHM=INSTANT;
DROP TABLE t1;
--echo #
--echo # MDEV-17301 Change of COLLATE unnecessarily requires ALGORITHM=COPY
--echo #
create table t (
a char(10) collate latin1_general_ci primary key,
b char(10) collate latin1_general_ci,
c char(10) collate latin1_general_ci,
unique key b_key(b)
) engine=innodb;
insert into t values
('aaa', 'aaa', 'aaa'), ('ccc', 'ccc', 'ccc'), ('bbb', 'bbb', 'bbb');
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify a char(10) collate latin1_general_cs, algorithm=inplace;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify b char(10) collate latin1_general_cs, algorithm=instant;
alter table t modify b char(10) collate latin1_general_cs, algorithm=nocopy;
check table t;
alter table t modify c char(10) collate latin1_general_cs, algorithm=instant;
check table t;
drop table t;
create table t (
a varchar(10) collate latin1_general_ci primary key,
b varchar(10) collate latin1_general_ci,
c varchar(10) collate latin1_general_ci,
unique key b_key(b)
) engine=innodb;
insert into t values
('aaa', 'aaa', 'aaa'), ('ccc', 'ccc', 'ccc'), ('bbb', 'bbb', 'bbb');
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify a varchar(10) collate latin1_general_cs, algorithm=inplace;
--error ER_ALTER_OPERATION_NOT_SUPPORTED_REASON
alter table t modify b varchar(10) collate latin1_general_cs, algorithm=instant;
alter table t modify b varchar(10) collate latin1_general_cs, algorithm=nocopy;
check table t;
alter table t modify c varchar(10) collate latin1_general_cs, algorithm=instant;
check table t;
drop table t;
--echo #
--echo # MDEV-20726: InnoDB: Assertion failure in file data0type.cc line 67
--echo #
CREATE TABLE t (
id int(10) unsigned NOT NULL PRIMARY KEY,
a text CHARSET utf8mb3,
KEY a_idx(a(1))
) ENGINE=InnoDB;
INSERT INTO t VALUES (1, 'something in the air');
ALTER TABLE t MODIFY a text CHARSET utf8mb4;
DROP TABLE t;
--echo #
--echo # MDEV-22899: Assertion `field->col->is_binary() || field->prefix_len % field->col->mbmaxlen == 0' failed in dict_index_add_to_cache
--echo #
CREATE TABLE t1 (
a text CHARACTER SET utf8 DEFAULT NULL,
KEY a_key (a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a text CHARACTER SET utf8 DEFAULT NULL,
b int,
KEY a_key (b, a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a char(200) CHARACTER SET utf8 DEFAULT NULL,
KEY a_key (a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a char(200) CHARACTER SET utf8 DEFAULT NULL,
b int,
KEY a_key (b, a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a varchar(200) CHARACTER SET utf8 DEFAULT NULL,
KEY a_key (a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a varchar(200) CHARACTER SET utf8 DEFAULT NULL,
b int,
KEY a_key (b, a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a varchar(2000) CHARACTER SET utf8 DEFAULT NULL,
KEY a_key (a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
CREATE TABLE t1 (
a varchar(2000) CHARACTER SET utf8 DEFAULT NULL,
b int,
KEY a_key (b, a(1))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ();
ALTER TABLE t1 MODIFY a text DEFAULT NULL;
DROP TABLE t1;
--echo #
--echo # MDEV-23245 Still getting assertion failure in file data0type.cc line 67
--echo #
CREATE TABLE Foo
(
Bar char(2) CHARACTER SET utf8,
KEY Bar (Bar(1))
) ENGINE = InnoDB;
ALTER TABLE Foo MODIFY Bar char(2) CHARACTER SET utf8mb4;
INSERT INTO Foo VALUES ('a');
DROP TABLE Foo;
CREATE TABLE Foo
(
Bar varchar(2) CHARACTER SET utf8,
KEY Bar (Bar(1))
) ENGINE = InnoDB;
ALTER TABLE Foo MODIFY Bar varchar(2) CHARACTER SET utf8mb4;
INSERT INTO Foo VALUES ('a');
DROP TABLE Foo;
CREATE TABLE Foo
(
Bar text CHARACTER SET utf8,
KEY Bar (Bar(1))
) ENGINE = InnoDB;
ALTER TABLE Foo MODIFY Bar text CHARACTER SET utf8mb4;
INSERT INTO Foo VALUES ('a');
DROP TABLE Foo;
CREATE TABLE t1 (a VARCHAR(2) CHARACTER SET utf8mb3 COLLATE utf8mb3_unicode_ci,
PRIMARY KEY (a(1)))
ENGINE=InnoDB;
SHOW CREATE TABLE t1;
ALTER TABLE t1 MODIFY a VARCHAR(2)
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
INSERT INTO t1 VALUES ('a');
DROP TABLE t1;
MDEV-22775 [HY000][1553] Changing name of primary key column with foreign key constraint fails. Problem: The problem happened because of a conceptual flaw in the server code: a. The table level CHARSET/COLLATE clause affected all data types, including numeric and temporal ones: CREATE TABLE t1 (a INT) CHARACTER SET utf8 [COLLATE utf8_general_ci]; In the above example, the Column_definition_attributes (and then the FRM record) for the column "a" erroneously inherited "utf8" as its character set. b. The "ALTER TABLE t1 CONVERT TO CHARACTER SET csname" statement also erroneously affected Column_definition_attributes::charset for numeric and temporal data types and wrote "csname" as their character set into FRM files. So now we have arbitrary non-relevant charset ID values for numeric and temporal data types in all FRM files in the world :) The code in the server and the other engines did not seem to be affected by this flaw. Only InnoDB inplace ALTER was affected. Solution: Fixing the code in the way that only character string data types (CHAR,VARCHAR,TEXT,ENUM,SET): - inherit the table level CHARSET/COLLATE clause - get the charset value according to "CONVERT TO CHARACTER SET csname". Numeric and temporal data types now always get &my_charset_numeric in Column_definition_attributes::charset and always write its ID into FRM files: - no matter what the table level CHARSET/COLLATE clause is, and - no matter what "CONVERT TO CHARACTER SET" says. Details: 1. Adding helper classes to pass small parts of HA_CREATE_INFO into Type_handler methods: - Column_derived_attributes - to pass table level CHARSET/COLLATE, so columns that do not have explicit CHARSET/COLLATE clauses can derive them from the table level, e.g. CREATE TABLE t1 (a VARCHAR(1), b CHAR(1)) CHARACTER SET utf8; - Column_bulk_alter_attributes - to pass bulk attribute changes generated by the ALTER related code. These bulk changes affect multiple columns at the same time: ALTER TABLE ... CONVERT TO CHARACTER SET csname; Note, passing the whole HA_CREATE_INFO directly to Type_handler would not be good: HA_CREATE_INFO is huge and would need not desired dependencies in sql_type.h and sql_type.cc. The Type_handler API should use smallest possible data types! 2. Type_handler::Column_definition_prepare_stage1() is now responsible to set Column_definition::charset properly, according to the data type, for example: - For string data types, Column_definition_attributes::charset is set from the table level CHARSET/COLLATE clause (if not specified explicitly in the column definition). - For numeric and temporal fields, Column_definition_attributes::charset is set to &my_charset_numeric, no matter what the table level CHARSET/COLLATE says. - For GEOMETRY, Column_definition_attributes::charset is set to &my_charset_bin, no matter what the table level CHARSET/COLLATE says. Previously this code (setting `charset`) was outside of of Column_definition_prepare_stage1(), namely in mysql_prepare_create_table(), and was erroneously called for all data types. 3. Adding Type_handler::Column_definition_bulk_alter(), to handle "ALTER TABLE .. CONVERT TO". Previously this code was inside get_sql_field_charset() and was erroneously called for all data types. 4. Removing the Schema_specification_st parameter from Type_handler::Column_definition_redefine_stage1(). Column_definition_attributes::charset is now fully properly initialized by Column_definition_prepare_stage1(). So we don't need access to the table level CHARSET/COLLATE clause in Column_definition_redefine_stage1() any more. 5. Other changes: - Removing global function get_sql_field_charset() - Moving the part of the former get_sql_field_charset(), which was responsible to inherit the table level CHARSET/COLLATE clause to new methods: -- Column_definition_attributes::explicit_or_derived_charset() and -- Column_definition::prepare_charset_for_string(). This code is only needed for string data types. Previously it was erroneously called for all data types. - Moving another part, which was responsible to apply the "CONVERT TO" clause, to Type_handler_general_purpose_string::Column_definition_bulk_alter(). - Replacing the call for get_sql_field_charset() in sql_partition.cc to sql_field->explicit_or_derived_charset() - it is perfectly enough. The old code was redundant: get_sql_field_charset() was called from sql_partition.cc only when there were no a "CONVERT TO CHARACTER SET" clause involved, so its purpose was only to inherit the table level CHARSET/COLLATE clause. - Moving the code handling the BINCMP_FLAG flag from mysql_prepare_create_table() to Column_definition::prepare_charset_for_string(): This code is responsible to resolve the BINARY comparison style into the corresponding _bin collation, to do the following transparent rewrite: CREATE TABLE t1 (a VARCHAR(10) BINARY) CHARSET utf8; -> CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_bin); This code is only needed for string data types. Previously it was erroneously called for all data types. 6. Renaming Table_scope_and_contents_source_pod_st::table_charset to alter_table_convert_to_charset, because the only purpose it's used for is handlering "ALTER .. CONVERT". The new name is much more self-descriptive.
2021-03-25 06:55:18 +04:00
--echo #
--echo # MDEV-22775 [HY000][1553] Changing name of primary key column with foreign key constraint fails.
--echo #
create table t1 (id int primary key) engine=innodb default charset=utf8;
create table t2 (input_id int primary key, id int not null,
key a (id),
constraint a foreign key (id) references t1 (id)
)engine=innodb default charset=utf8;
alter table t1 change id id2 int;
drop table t2;
drop table t1;
--echo #
--echo # MDEV-25951 MariaDB crash after ALTER TABLE convert to utf8mb4
--echo #
CREATE TABLE t1 (id INT PRIMARY KEY, a VARCHAR(32), KEY (a(7))) ENGINE=INNODB DEFAULT CHARSET=UTF8;
INSERT INTO t1 VALUES (1, 'a1'), (2, 'a1');
--error ER_DUP_ENTRY
ALTER TABLE t1
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci,
ADD UNIQUE INDEX test_key (a);
ALTER TABLE t1 CONVERT TO CHARACTER SET UTF8MB4 COLLATE UTF8MB4_UNICODE_520_CI;
CHECK TABLE t1;
SELECT * FROM t1;
DROP TABLE t1;
CREATE TABLE t1 (id INT PRIMARY KEY, a CHAR(32), KEY (a(7))) ENGINE=INNODB DEFAULT CHARSET=UTF8;
INSERT INTO t1 VALUES (1, 'a1'), (2, 'a1');
--error ER_DUP_ENTRY
ALTER TABLE t1
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci,
ADD UNIQUE INDEX test_key (a);
ALTER TABLE t1 CONVERT TO CHARACTER SET UTF8MB4 COLLATE UTF8MB4_UNICODE_520_CI;
CHECK TABLE t1;
SELECT * FROM t1;
DROP TABLE t1;