• Tatiana A. Nurnberg's avatar
    Bug#43508: Renaming timestamp or date column triggers table copy · 74deaae9
    Tatiana A. Nurnberg authored
    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.
    74deaae9
sql_table.cc 246 KB