Hi Ann!
According to the bug report, it is the search key that ends with a
byte that is 0x20, not the values of the fields, so the problem is
probably some other place.
Thanks :)
What I can do is:
mysql>select * from t1 where s1 < 'Ġ';;
+------+
| s1 |
+------+
| ā |
+------+
1 row in set (0.00 sec)
mysql> create index i on t1 (s1);
Query OK, 0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> select * from t1 where s1 < 'Ġ';
+------+
| s1 |
+------+
| ā |
+------+
1 row in set (0.00 sec)
In the bug report, however, what is returned is
+------+
| s1 |
+------+
| Ā |
+------+
and only if the field is indexed
/Lars-Erik
On Oct 22, 2008, at 9:55 PM, Ann W. Harrison wrote:
> Lars-Erik,
>> Thanks for the explanation, I was wondering because I am able to
>> reproduce bug#34479, that we discussed on the Friday conf. call
>> even without adding indexes to the field.
>
> I've got a guess on that. UCS2 is not one of the character sets
> Jim uses a lot - he's distinctly a UTF-8 kind of guy, and I think
> that encode data may be handling trailing 0x20 bytes incorrectly
> for UCS2.
>
> What I would do is follow a UCS2 string that ends in a 0x20 through
> encodeRecord and encodeOpaque and see if it loses its trailing byte.
> If so, when decoded, you're likely to get whatever happens to be in
> the buffer as the second half of the last character.
>
> Which reminds me that in general, using UCS2, the code that
> truncates blanks needs to look for pairs of 0x20 0x00, not
> 0x20 bytes. And the other fixed size, multi-byte character
> sets need special handling as well.
>
> Best regards,
>
>
> Ann
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
>
