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.

0 files changed, 0 insertions, 0 deletions