When InnoDB compares varchar field in ucs2 with given key using bin collation,
it calls my_strnncollsp_ucs2_bin() to perform comparison.
Because field length was lesser than length of key field should be padded
with trailing spaces in order to get correct result.
Because my_strnncollsp_ucs2_bin() was calling my_strnncollp_ucs2_bin(), which
doesn't pads field, wrong comparison result was returned. This results in
wrong result set.
my_strnncollsp_ucs2_bin() now compares fields like my_strnncollsp_ucs2 do,
but using binary collation.
field.cc:
BLOB variations have number-in-bytes limit,
unlike CHAR/VARCHAR which have number-of-characters limits.
A tinyblob column can store up to 255 bytes.
In the case of basic Latin letters (which use 1 byte per character)
we can store up to 255 characters in a tinyblob column.
When passing an utf8 tinyblob column as an argument into
a function (e.g. COALESCE) we need to reserve 3*255 bytes.
I.e. multiply length in bytes to mbcharlen for the character set.
Although in reality a tinyblob column can never be 3*255 bytes long,
we need to set max_length to multiply to make fix_length_and_dec()
of the function-caller (e.g. COALESCE) calculate the correct max_length
for the column being created.
ctype_utf8.result, ctype_utf8.test:
Adding test case.
for uca collation isalnum and strnncollsp don't agree on whether
0xC2A0 is a space (strnncollsp is right, isalnum is wrong).
they still don't, the bug was fixed by avoiding strnncollsp
table' lockup".
Changes from the innodb-4.1-ss11 snapshot.
Do not call os_file-create_tmpfile() at runtime. Instead, create
a tempfile at startup and guard access to it with a mutex.
Also, fix bugs:
10511: "Wrong padding of UCS2 CHAR columns in ON UPDATE CASCADE";
13778: "If FOREIGN_KEY_CHECKS=0, one can create inconsistent FOREIGN
KEYs". When FOREIGN_KEY_CHECKS=0 we still need to check that
datatypes between foreign key references are compatible.
Also, added test cases (also for bug 9802).
into parts when converting to Unicode.
m_ctype.h:
Reorganizing mb_wc return codes to be able
to return "an unassigned N-byte-long character".
sql_string.cc:
Adding code to detect and properly handle
unassigned characters (i.e. the those character
which are correctly formed according to the
character specifications, but don't have Unicode
mapping).
Many files:
Fixing conversion function to return new codes.
ctype_ujis.test, ctype_gbk.test, ctype_big5.test:
Adding a test case.
ctype_ujis.result, ctype_gbk.result, ctype_big5.result:
Fixing results accordingly.
Fix for bug#12429: Replication tests fail: "Slave_IO_Running" differs:
The value is not important, and it depends on timing. Mask it.
Backport and extension of a fix made by Matthias in 5.0, originally it was
1.1976 05/12/05 17:57:48 mleich@mysql.com
ctype-euc_kr.c:
ctype-gb2312.c:
Adding specific well_formed_length functions
for gb2312 and euckr, to allow storing characters
which are correct according to the character set
specifications but just don't have Unicode mapping.
Previously only those which have Unicode mapping
could be stored, while unassigned characters lead
to data truncation.
Many files:
new file
Problem #1: INSERT...SELECT, Version for 4.1.
INSERT ... SELECT with the same table on both sides (hidden
below a MERGE table) does now work by buffering the select result.
The duplicate detection works now after open_and_lock_tables()
on the locks.
I did not find a test case that failed without the change in
sql_update.cc. I made the change anyway as it should in theory
fix a possible MERGE table problem with multi-table update.
- Set max_length of Item_func_uuid to max_length*system_charset_info->mbmaxlen
Note! Item_func_uuid should be set to use 'ascii' charset when hex(), format(), md5()
etc will use 'ascii'
- Comitting again, the old patch seems to have been lost.
field.cc:
Adding longlong range checking to return
LONGLONG_MIN or LONGLONG_MAX when out of range.
Using (longlong) cast only when range is ok.
cast.test:
Adding test case.
cast.result:
Fixing results accordingly.
depending on table order
multi_update::send_data() was counting updates, not updated rows. Thus if one
record have several updates it will be counted several times in 'rows matched'
but updated only once.
multi_update::send_data() now counts only unique rows.
Problem #1: INSERT...SELECT
INSERT ... SELECT with the same table on both sides (hidden
below a MERGE table) does now work by buffering the select result.
The duplicate detection works now after open_and_lock_tables()
on the locks.
I did not find a test case that failed without the change in
sql_update.cc. I made the change anyway as it should in theory
fix a possible MERGE table problem with multi-table update.
CREATE TABLE and PS/SP": make sure that 'typelib' object for
ENUM values and 'Item_string' object for DEFAULT clause are
created in the statement memory root.
crash
resolve_const_item() substitutes item which will evaluate to constant with
equvalent constant item, basing on the item's result type. In this case
subselect was resolved as constant, and resolve_const_item() was substituting
it's result's Item_caches to Item_null. Later Item_cache's function was called
for Item_null object, which caused server crash.
resolve_const_item() now substitutes constants for items with
result_type == ROW_RESULT only for Item_rows.
