At 10:07 AM -0500 2000-03-18, Tom Emerson wrote:
>So, I guess the two questions I have are:
>1) Why was the behavior changed?
>2) Is there a good reason why SET members should not be compared in a
Probably because the comparisons are done on the underlying numeric
values that are used to represent SET values. That's just a guess.
>I agree with you that the possible rational you suggest seems to be a
>stretch: it is certainly *not* the behavior that I expected.
>I suppose one could have a "BINARY" set, though that doesn't make much sense
>Thanks: I think I'll submit a bug report and patch and see what happens.
>From: Ryan Caveney [mailto:rcaveney@stripped]
>Sent: Friday, March 17, 2000 3:17 PM
>To: Tom Emerson; mysql@stripped
>Subject: Re: Case sensitivity in SET members
>Tom Emerson <Tree@stripped> wrote:
>>are SET values supposed to be treated in a case insensitive way? Consider:
>According to Paul DuBois's book (page 506), SET comparisons are not case
>sensitive anymore, but were in versions before 3.22.1.
>>So it would seem that while the mixed-case SET members are stored, you can
>>only refer to them by their bit value, not by string value.
>I suppose it could be sais this behavior is sort of like the TEXT and
>non-BINARY (VAR)CHAR columns: you compare in any way you like, but the data
>comes out with whatever case mixture it went in with. I don't find that
>very compelling reasoning, however, because this affects what you're allowed
>to insert as well as select.
Paul DuBois, paul@stripped