Bug#58190 BETWEEN no longer uses indexes for date or datetime fields

Regression introduced by WL#2649.

Problem: queries with date/datetime columns did not use indexes:
set names non_latin1_charset;
select * from date_index_test
where date_column between '2010-09-01' and '2010-10-01';

before WL#2649 indexes worked fine because charset of 
date/datetime
columns was BINARY which always won.

Fix: testing that collation of the operation matches collation 
of the field is only needed in case of "real" string data types.
For DATE, DATETIME it's not needed.


  @ mysql-test/include/ctype_numconv.inc
  @ mysql-test/r/ctype_binary.result
  @ mysql-test/r/ctype_cp1251.result
  @ mysql-test/r/ctype_latin1.result
  @ mysql-test/r/ctype_ucs.result
  @ mysql-test/r/ctype_utf8.result
  Adding tests

  @ sql/field.h
  Adding new method Field_str::match_collation_to_optimize_range()
  for use in opt_range.cc to distinguish between
  "real string" types like CHAR, VARCHAR, TEXT
  (Field_string, Field_varstring, Field_blob)

  and "almost string" types DATE, TIME, DATETIME
  (Field_newdate, Field_datetime, Field_time, Field_timestamp)

  @ sql/opt_range.cc
  Using new method instead of checking result_type() against STRING result.

Note:

  Another part of this problem (which is not regression) 
  is submitted separately (see bug##58329).

sql/opt_range.cc

@@ -5796,6 +5796,7 @@ get_mm_leaf(RANGE_OPT_PARAM *param, COND *conf_func, Field *field,
 
   */
   if (field->result_type() == STRING_RESULT &&
+      ((Field_str*) field)->match_collation_to_optimize_range() &&
       value->result_type() == STRING_RESULT &&
       key_part->image_type == Field::itRAW &&
       ((Field_str*)field)->charset() != conf_func->compare_collation() &&