Bug#24660: "enum" field type definition problem
ENUMs weren't allowed to have character 0xff, a perfectly good character in many locales. This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from being used (because they too would get converted to 0xff on load). Now if 0xff makes an appearance, we find a character not used in the enum and use that as a separator. If no such character exists, we throw an error. Any solution would have broken some sort of existing behaviour. This solution should serve both fractions (those with 0xff and those with ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current server, and restore when upgrading to one with this patch. (port of the original 4.1 patch. incorporates some suggestions by kaamos.) mysql-test/r/type_enum.result: Bug#24660: "enum" field type definition problem Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable char in some locales), or ',', or both. mysql-test/t/type_enum.test: Bug#24660: "enum" field type definition problem Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable char in some locales), or ',', or both. sql/table.cc: Bug#24660: "enum" field type definition problem Revert fix for Bug#20922. sql/unireg.cc: Bug#24660: "enum" field type definition problem Use a field-separator for ENUM-values that is not part of those values. If impossible, throw error.
Showing
Please register or sign in to comment