Hi Ann and Kevin,
Kevin Lewis wrote:
> Expanding on what Ann wrote:
> Ann W. Harrison wrote:
>> Expanding on what Kevin Lewis wrote:
>>> >> Bar wrote;
>>>>> Sorry, I'm not strong with Falcon internals,
>>>>> so I don't know why you need to trim trailing minSortChar.
>>>>> This makes MySQLCollation::compare() work differently from
>>>>> how collation really works.
>>>>> Can you please give some insight for this?
>>> > Lars-Erik Bjørk wrote:
>>>> I think I will pass that one on to somebody else:) Maybe you could
>>>> explain this briefly, Kevin?
>>> The Falcon internal encoded record does not store trailing white
>>> space. Jim Starkey has declared many times that he is on a mission
>>> to replace the use of char[anything], varchar[anything], etc with
>>> just 'string'. Falcon does that internally. I also see no reason to
>>> store what does not matter.
>> To clarify slightly, Falcon removes trailing spaces from strings, it
>> does not remove trailing tab characters which are often called "white
>> One problem with removing trailing spaces is that some values that
>> can appear in strings sort lower than the space character, and the SQL
>> standard says that in a string comparison the shorter string is to be
>> padded with spaces to the length of the longer string. As long
>> as all strings are space padded to their full length, that doesn't
>> matter - the comparisons work naturally.
>> However, when comparing strings of different lengths, the right
>> answer is less obvious. Logically it would seem that a two character
>> string sorts lower than any three character string that starts with
>> the same two characters. Logic, SQL, and mother of all character
>> sets, ASCII, aren't a good combination.
>> The correct order of these strings (in most collations) is...
>> For a long time, Falcon got that wrong in indexes and considered
>> 'ab' to be less than 'ab<0x0>'. Recently, Kevin had a brilliant
>> idea. When handling a string key value, both for storage and for
>> comparison, add an imaginary space to it. There's no reason to
>> store the space as long as everyone behaves as if it were stored.
>> So now the values above are treated as if they were:
>> which, however ugly, is at least clear.
> Well this is not quite yet implemented. The bug is being worked on by
> Lars-Erik and does not have a BETA tag. I think it is;
> Bug #23692 Falcon: searches fail if data is 0x00
Thanks for your comments.
That's true , <tab> in many collations is the smallest character
(i.e. minSortChar=<tab>), and space is greater than <tab>.
So does not seem correct to remove both spaces and tabs, and
then execute strnncoll() for the results in the patch for
I'm setting the bug back to "In progress" state.
Please suggest some solution to Lars-Erik.