bk commit into 4.1 tree (heikki:1.2065)

[Heikki Tuuri]

Below is the list of changes that have just been committed into a local
4.1 repository of heikki. When heikki does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.2065 04/10/08 15:25:59 heikki@stripped +2 -0
  row0sel.c, row0row.c:
    Fix bug #5975 about UTF-8 chars and prefix indexes; do not print warnings if a column
prefix is > 255 bytes

  innobase/row/row0sel.c
    1.57 04/10/08 15:25:41 heikki@stripped +19 -12
    Fix bug #5975 about UTF-8 chars and prefix indexes; do not print warnings if a column
prefix is > 255 bytes

  innobase/row/row0row.c
    1.13 04/10/08 15:25:41 heikki@stripped +10 -6
    Fix bug #5975 about UTF-8 chars and prefix indexes; do not print warnings if a column
prefix is > 255 bytes

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	heikki
# Host:	hundin.mysql.fi
# Root:	/home/heikki/mysql-4.1

--- 1.12/innobase/row/row0row.c	Wed Oct  6 15:09:38 2004
+++ 1.13/innobase/row/row0row.c	Fri Oct  8 15:25:41 2004
@@ -386,10 +386,12 @@
 			dict_index_get_nth_field(clust_index, i)->prefix_len;
 
 		if (clust_col_prefix_len > 0) {
-		    	if (len != UNIV_SQL_NULL
-			    && len > clust_col_prefix_len) {
+		    	if (len != UNIV_SQL_NULL) {
 
-				dfield_set_len(dfield, clust_col_prefix_len);
+				dfield_set_len(dfield,
+				  dtype_get_at_most_n_mbchars(
+					dfield_get_type(dfield),
+					clust_col_prefix_len, len, field));
 			}
 		}
 	}
@@ -471,10 +473,12 @@
 			dict_index_get_nth_field(clust_index, i)->prefix_len;
 
 		if (clust_col_prefix_len > 0) {
-		    	if (len != UNIV_SQL_NULL
-			    && len > clust_col_prefix_len) {
+		    	if (len != UNIV_SQL_NULL) {
 
-				dfield_set_len(dfield, clust_col_prefix_len);
+				dfield_set_len(dfield,
+				  dtype_get_at_most_n_mbchars(
+					dfield_get_type(dfield),
+					clust_col_prefix_len, len, field));
 			}
 		}
 	}

--- 1.56/innobase/row/row0sel.c	Fri Oct  1 20:00:57 2004
+++ 1.57/innobase/row/row0sel.c	Fri Oct  8 15:25:41 2004
@@ -2024,19 +2024,15 @@
 
 			/* MySQL stores the actual data length to the first 2
 			bytes after the optional SQL NULL marker byte. The
-			storage format is little-endian. */
+			storage format is little-endian, that is, the most
+			significant byte at a higher address. In UTF-8, MySQL
+			seems to reserve field->prefix_len bytes for
+			storing this field in the key value buffer, even
+			though the actual value only takes data_len bytes
+			from the start. */
 
-			/* There are no key fields > 255 bytes currently in
-			MySQL */
-			if (key_ptr[data_offset + 1] != 0) {
-				ut_print_timestamp(stderr);
-				fputs(
-"  InnoDB: Error: BLOB or TEXT prefix > 255 bytes in query to table ", stderr);
-				ut_print_name(stderr, trx, index->table_name);
-				putc('\n', stderr);
-			}
-
-			data_len = key_ptr[data_offset];
+			data_len = key_ptr[data_offset]
+				   + 256 * key_ptr[data_offset + 1];
 			data_field_len = data_offset + 2 + field->prefix_len;
 			data_offset += 2;
 			
@@ -2044,6 +2040,17 @@
 					  store the column value like it would
 					  be a fixed char field */
 		} else if (field->prefix_len > 0) {
+			/* Looks like MySQL pads unused end bytes in the
+			prefix with space. Therefore, also in UTF-8, it is ok
+			to compare with a prefix containing full prefix_len
+			bytes, and no need to take at most prefix_len / 3
+			UTF-8 characters from the start.
+			If the prefix is used as the upper end of a LIKE
+			'abc%' query, then MySQL pads the end with chars
+			0xff. TODO: in that case does it any harm to compare
+			with the full prefix_len bytes. How do characters
+			0xff in UTF-8 behave? */
+
 		        data_len = field->prefix_len;
 			data_field_len = data_offset + data_len;
 		} else {