"Jim Starkey" <jas@...> wrote in message
news:4228A769.1040805@......

> Good. Let's accept the idea that there are different flavors of case
> insensitivity. I think we can also agree that a collation is required
> to define case insensitivity for a particular language. The question is
> whether case insensitivity is, in fact, just a collation, or something a
> little stronger. The difference, I think, is in the definition of the
> equality operator. For field declared as case insensitive, two values
> can be different but still equal.

They have the same comparison key. So they are the same in terms of
comparison. Nothing new.

Furthermore, a comparison of field

> that is case insensitive to a case sensitive value must be performed

Hm, I thought everyone agreed that collations is an attribute of an
operation, not data. Of course, it is convinient to define default collation
for a field, but it solely to derive a collation for further operations. How
such derivation is performed and how would fields with different collations
compared (if compared at all) is a different topic.

Storing strings in Unicode has other issues to consider. As a user chooses
Unicode to store strings, he assumes to have chars of different languages in
that field. In that case it seems to be meaningless to assign a collation
(which is bound to a particular language) to that field entirely. Of course,
there is (are?) so called universal collation for unicode, but it is no
better than binary collation for many languages. To avoid the problem, a
user can apply a collation to the result of filtered query, eg SELECT title
FROM books WHERE lang='rus' ORDER BY title COLLATE(RU_RU).

Regards,
Aleksey Karyakin