Hello Jim,

Friday, March 4, 2005, 1:48:54 PM, you wrote:

> Aleksey Karyakin wrote:

>>"
>>
>>
>>If all
>>
>>
>>>indexes are based on UTF-8, the character set used by the client
>>>
>>>
>>doesn't
>>
>>
>>>come into the equation at all.
>>>
>>>
>>
>>I'm afraid no. What about case-insensitive, accent-insensitive, etc
>>comparisons which are all language-specific?
>>
>>
> Of course they're language specific. But the the collations can be
> written to operator on UTF-8 as well (or better) than a language
> specific character set.

>>There actually are case-insensitive collations in current codebase
>>but I would prefer the other way to handle this. Let a collation
>>defines multi-level key strings to use in indexes and comparisons and
>>an operation itself specifies if it wish to skip any of secondary
>>weights. So CASE-INSENSITIVE, etc would be an attribute of
>>index/operation not of a collation. Thus we end up with significatnt
>>less number of collations preserving vide range of comparison options.
>>
>>
> I think the question of case-insensitivity is an interesting case. In
> general, collation is only necessary for a high/low test -- sorting and
> range retrievals, while equality can be based on raw byte comparison.
> To support case insensitivity, collation is required to determine even
> equality.

> Are there other collations where equality is collation specific?

Accent insensitivity combined with case insensitivity equalities.

--
Best regards,
Daniel Rail
Senior Software Developer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)