Fix for bug#50946: fast index creation still seems to copy the table

Problem: ALTER TABLE ADD INDEX may lead to table copying if there's
numeric field(s) with non-default display width modificator specified.

Fix: compare numeric field's storage lenghts when we decide whether 
they can be considered 'equal' for table alteration purposes.


mysql-test/r/error_simulation.result:
  Fix for bug#50946: fast index creation still seems to copy the table
    - test result.
mysql-test/t/error_simulation.test:
  Fix for bug#50946: fast index creation still seems to copy the table
    - test case.
sql/field.cc:
  Fix for bug#50946: fast index creation still seems to copy the table
    - check numeric field's pack lengths instead of it's display lenghts
  comparing fields equality for table alteration purposes.
sql/sql_table.cc:
  Fix for bug#50946: fast index creation still seems to copy the table
    - check compare_tables() result for testing purposes.

1 files changed, 9 insertions, 3 deletions

diff --git a/sql/field.cc b/sql/field.cc
index b6323d7b839..b203a42a918 100644
--- a/sql/field.cc
+++ b/sql/field.cc
@@ -8878,14 +8878,20 @@ bool Field_num::eq_def(Field *field)
 }
 
 
+/**
+  Check whether two numeric fields can be considered 'equal' for table
+  alteration purposes. Fields are equal if they are of the same type
+  and retain the same pack length.
+*/
+
 uint Field_num::is_equal(Create_field *new_field)
 {
   return ((new_field->sql_type == real_type()) &&
-	  ((new_field->flags & UNSIGNED_FLAG) == (uint) (flags &
-							 UNSIGNED_FLAG)) &&
+          ((new_field->flags & UNSIGNED_FLAG) == 
+           (uint) (flags & UNSIGNED_FLAG)) &&
 	  ((new_field->flags & AUTO_INCREMENT_FLAG) ==
 	   (uint) (flags & AUTO_INCREMENT_FLAG)) &&
-	  (new_field->length <= max_display_length()));
+          (new_field->pack_length == pack_length()));
 }