At 09:37 AM 3/29/00 -0700, you wrote:

>From: Tim Uckun <tim@...>
>
>
>>This seem like a reasonable thing to ask for. Are you suggesting
>>that sometimes people want to see an alphabetical list that is
>>not all caps?
>>
>>Great idea. Let's do it. The day after the source goes public
>>I'll lead the charge.
>
>When I do a search for where something="somevalue" I want to get the same
>result set as when I do something="SomeValue". So yes I guess I am saying
>that. I want to store the data anyway I want so that when I send out my
>mailing lists Mr. MacFadden does not get pissed off that we messed up his
>name. OTOH when Mr. MacFadden calls and wants to talk about his account I
>want my employees to be able to find his record without knowing how it's
>capitilized.
>

Good point. Case insensitive sorting is part of a full solution,
but not all of it. Sounds like we need some or all of the
following:

1. Case insensitive search operator
2. Case insensitive indexes
3. String fields marked as case insensitive

I'm not at all sure about #3. It tempting to just declare a field
as case insensitive and be done with it, but it raises all sorts
of problems such as operator to use when comparing fields of
differing sensitivies, definition of primary keys, etc.

I'm inclined to think that #1 is required, and #2 is necessary
to optimize #1. #3 may be desirable, but isn't obviously necessary,
so maybe we should just think about it until we have some experience.

Anybody have any ideas for an operation to unscramble Mr. Macfadden,
Mr. MacFadden, and Mr. MacFadDen?

Jim Starkey