You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Comparing tables with TableCharsetCollateStrategy = TableCharsetCollateIgnoreAlways or TableCharsetCollateIgnoreEmpty can generate a wrong plan depending on column definitions. As example: take these from and to statements:
from: "create table t (a varchar(64)) default charset=latin1",
to: "create table t (a varchar(64) CHARACTER SET latin1 COLLATE latin1_bin)",
In the from definition, a's charset is really latin1, derived from the table. So is the charset in to, defined explicitly.
However, when converting between the two tables in TableCharsetCollateIgnoreAlways, the fact the table charset is ignored leads to the wrong behavior where the column's charset is modified.
PR is incoming with test cases and fixes.
The text was updated successfully, but these errors were encountered:
Comparing tables with
TableCharsetCollateStrategy
=TableCharsetCollateIgnoreAlways
orTableCharsetCollateIgnoreEmpty
can generate a wrong plan depending on column definitions. As example: take thesefrom
andto
statements:In the
from
definition,a
's charset is reallylatin1
, derived from the table. So is the charset into
, defined explicitly.However, when converting between the two tables in
TableCharsetCollateIgnoreAlways
, the fact the table charset is ignored leads to the wrong behavior where the column's charset is modified.PR is incoming with test cases and fixes.
The text was updated successfully, but these errors were encountered: