Bug#43508: Renaming timestamp or date column triggers table copy
Altering a table to update a column with types DATE or TIMESTAMP would incorrectly be seen as a significant change that necessitates a slow copy+rename operation instead of a fast update. There were two problems: The character set is magically set for TIMESTAMP to be "binary", but that was done too deep in field use code for ALTER TABLE to know of it. Now, put that in the constructor for Field_timestamp. Also, when we set the character set for the new replacement/ comparison field, also raise the "binary" field flag that tells us we should compare it exactly. That is necessary to match the old stored definition. Next is the problem that the default length for TIMESTAMP and DATE fields is different than the length read from the .frm . The compressed size is written to the file, but the human-readable, part-delimited length is used as default length. IIRC, for timestamp it was 19!=14, and for date it was 8!=10. Length mismatch causes a table copy. Also, clean up a place where a comparison function alters one of its parameters and replace it with an assertion of the condition it mutates.
Showing
Please register or sign in to comment