MySQL Bugs: #30282: Falcon: duplicate-key error for value that ends with 0x00

Bug #30282	Falcon: duplicate-key error for value that ends with 0x00
Submitted:	7 Aug 2007 20:42	Modified:	18 Dec 2008 15:13
Reporter:	Peter Gulutzan
Status:	Duplicate
Category:	Server: Falcon	Severity:	S2 (Serious)
Version:	6.0-falcon	OS:	Any
Assigned to:	Lars-Erik Bjørk	Target Version:
Tags:	F_ENCODING
Triage:	Triaged: D2 (Serious) / R3 (Medium) / E3 (Medium)

Description:
I create a Falcon table with an indexed CHAR column.
I insert two values: 0x20 and 0x00.
I can see that the values are distinct, because
if I SELECT DISTINCT, or if I separately select
"WHERE ... = 0x20" and "WHERE ... = 0x00", I
get results that could only be true if Falcon
considers that 0x20 <> 0x00.
I try to create a unique index on the table.
I fail. Falcon says there is a duplicate key.

I consider that this is not a duplicate of
Bug#23692 Falcon: searches fail if data is 0x00
because there are no ">" or "<" comparisons.
In fact "=" comparisons succeed. Only uniqueness
tests fail.

How to repeat:
mysql> create table t6 (s1 char(1)) engine=falcon;
Query OK, 0 rows affected (0.02 sec)

mysql> insert into t6 values (0x20),(0x00);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> select * from t6 where s1 = 0x20;
+------+
| s1   |
+------+
|      |
+------+
1 row in set (0.00 sec)

mysql> select * from t6 where s1 = 0x00;
+------+
| s1   |
+------+
|      |
+------+
1 row in set (0.00 sec)

mysql> create unique index i6 on t6 (s1);
ERROR 1582 (23000): Duplicate entry '' for key 'i6'

Thank you for the bug report. Verified as described.

Added test case falcon_bug_30282.test and pushed to 5.1-falcon tree.

This bug affects the ujs character set. To reproduce, run:

perl mysql-test-run.pl --mysqld=--default-storage-engine=falcon ctype_ujis_ucs2

Another character-set related bug.

I am pretty sure that this is a duplicate of bug#34479 Falcon: search failure with indexed
ucs2 varchar.

I have also tested the reported queries against a sandbox version containing an
incomplete fix for 34479 (will fail for like searches and multi-field keys) and the
problem is not reproducible there. 

I will look a little deeper and probably close as a duplicate.

It seems that MySQLCollation::computeKeyLength returns a length of 0 for both of these
values, because it is removing trailing spaces regardless of the charset, as well as
removing trailing zeroes. 

I am closing this as a duplicate of bug#34479