ha_innodb.cc:

  Clarify the meaning of HA_READ_PREFIX_LAST as a search flag. InnoDB assumed the meaning wrong.


sql/ha_innodb.cc:
  Clarify the meaning of HA_READ_PREFIX_LAST as a search flag. InnoDB assumed the meaning wrong.

1 files changed, 8 insertions, 11 deletions

diff --git a/sql/ha_innodb.cc b/sql/ha_innodb.cc
index 52aeefc5cfe..fce9500a47c 100644
--- a/sql/ha_innodb.cc
+++ b/sql/ha_innodb.cc
@@ -2256,17 +2256,14 @@ convert_search_mode_to_innobase(
 		case HA_READ_BEFORE_KEY:	return(PAGE_CUR_L);
 		case HA_READ_PREFIX:		return(PAGE_CUR_GE);
 	        case HA_READ_PREFIX_LAST:       return(PAGE_CUR_LE);
-		  /*  TODO: 1) this should really be
-		      return(PAGE_CUR_LE_OR_EXTENDS); but since MySQL uses
-		      a wrong flag in search, we convert this to PAGE_CUR_LE;
-		      2) if the character set is not latin1, then InnoDB
-		      uses a MySQL function innobase_mysql_cmp() to
-		      compare CHAR and VARCHAR strings; since that function
-		      does not return the number of matched bytes,
-		      PAGE_CUR_LE_OR_EXTENDS does not currently work: we
-		      should probably write my_sortncmp_with_n_matcehd_bytes()
-		      to determine if a field 'extends' another;
-		      see dev-public discussion on Feb 7th, 2003 */
+		  /* In MySQL HA_READ_PREFIX and HA_READ_PREFIX_LAST always
+		  use a complete-field-prefix of a kay value as the search
+		  tuple. I.e., it is not allowed that the last field would
+		  just contain n first bytes of the full field value.
+		  MySQL uses a 'padding' trick to convert LIKE 'abc%'
+		  type queries so that it can use as a search tuple
+		  a complete-field-prefix of a key value. Thus, the InnoDB
+		  search mode PAGE_CUR_LE_OR_EXTENDS is never used. */
 		default:			assert(0);
 	}