1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge heikki@build.mysql.com:/home/bk/mysql-4.1

Browse Source 
into hundin.mysql.fi:/home/heikki/mysql-4.1
This commit is contained in:
unknown 2004-10-08 15:29:36 +03:00
commit 82343427f0
2 changed files with 29 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
innobase/row/row0row.c
View File

@ -386,10 +386,12 @@ row_build_row_ref(
dict_index_get_nth_field(clust_index, i)->prefix_len; dict_index_get_nth_field(clust_index, i)->prefix_len;
if (clust_col_prefix_len > 0) { if (clust_col_prefix_len > 0) {
if (len != UNIV_SQL_NULL if (len != UNIV_SQL_NULL) {
&& len > clust_col_prefix_len) {
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 @@ row_build_row_ref_in_tuple(
dict_index_get_nth_field(clust_index, i)->prefix_len; dict_index_get_nth_field(clust_index, i)->prefix_len;
if (clust_col_prefix_len > 0) { if (clust_col_prefix_len > 0) {
if (len != UNIV_SQL_NULL if (len != UNIV_SQL_NULL) {
&& len > clust_col_prefix_len) {
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));
} }
} }
} }

31
innobase/row/row0sel.c
View File

@ -2024,19 +2024,15 @@ row_sel_convert_mysql_key_to_innobase(
/* MySQL stores the actual data length to the first 2 /* MySQL stores the actual data length to the first 2
bytes after the optional SQL NULL marker byte. The 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 data_len = key_ptr[data_offset]
MySQL */ + 256 * key_ptr[data_offset + 1];
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_field_len = data_offset + 2 + field->prefix_len; data_field_len = data_offset + 2 + field->prefix_len;
data_offset += 2; data_offset += 2;
@ -2044,6 +2040,17 @@ row_sel_convert_mysql_key_to_innobase(
store the column value like it would store the column value like it would
be a fixed char field */ be a fixed char field */
} else if (field->prefix_len > 0) { } 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_len = field->prefix_len;
data_field_len = data_offset + data_len; data_field_len = data_offset + data_len;
} else { } else {