From 1dc1f7959aede33871ce975f556c46d1afbd2092 Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 18 Feb 2003 20:07:06 +0200 Subject: ha_innodb.cc: Add comment about how to modify InnoDB to deal with partial-field prefixes of key value in the future sql/ha_innodb.cc: Add comment about how to modify InnoDB to deal with partial-field prefixes of key value in the future --- sql/ha_innodb.cc | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) (limited to 'sql') diff --git a/sql/ha_innodb.cc b/sql/ha_innodb.cc index 3ceb5cbeb36..b1f1911858d 100644 --- a/sql/ha_innodb.cc +++ b/sql/ha_innodb.cc @@ -2257,13 +2257,19 @@ convert_search_mode_to_innobase( case HA_READ_PREFIX: return(PAGE_CUR_GE); case HA_READ_PREFIX_LAST: return(PAGE_CUR_LE); /* In MySQL-4.0 HA_READ_PREFIX and HA_READ_PREFIX_LAST always - pass a complete-field-prefix of a key value as the search + pass a complete-field prefix of a key 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. */ + search mode PAGE_CUR_LE_OR_EXTENDS is never used. + TODO: when/if MySQL starts to use also partial-field + prefixes, we have to deal with stripping of spaces + and comparison of non-latin1 char type fields in + innobase_mysql_cmp() to get PAGE_CUR_LE_OR_EXTENDS to + work correctly. */ + default: assert(0); } -- cgit v1.2.1