From a811b06b30b6ad3c8ac286f389a50e4f71f6a909 Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 7 Feb 2003 17:33:15 +0200 Subject: 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. --- sql/ha_innodb.cc | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) (limited to 'sql/ha_innodb.cc') 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); } -- cgit v1.2.1