>>>>> "Jerome" == Jerome Abela <Jerome.Abela@stripped> writes:
Jerome> Monty writes:
>> MySQL 3.23.24 is now released
>> Users that are using 3.23.23 should upgrade to this version! If you
>> are are using 3.23.23 and have keys on CHAR, VARCHAR or BLOB columns
>> that may contain characters > 128 (like Scandinavia characters), you
>> should run a CHECK on all tables and REPAIR any tables for which you
>> get an warning!
Jerome> Could you please elaborate a little bit on this ?
Jerome> - You say that 3.23.23 tables should be repaired
Jerome> - The manual says that 3.23.22 tables should be repaired
The manual was wrong, I have now updated the manual about this.
Jerome> - I feel concerned about this statement from the manual: "Changed sort
Jerome> order for latin1 as it was before 3.23.22"
It should be as before 3.23.23.
Jerome> Indeed, as it was discussed on this list, the following characters are
Jerome> compared as equal with 3.23.23:
Jerome> A a À Á Â Ã Ä Å à á
> â ã ä å
Jerome> However, with 3.23.22, only the following ones are equal:
Jerome> A a À Á Â Ã à á â ã
Jerome> Are you telling us that 3.23.24 is getting back to the 3.23.22 behaviour ?
Yes; The reason is that the above is how we compare things in
at least Sweden and Finland; If we change the comparison for the
latin1 set, we will crash everything for users here in Scandinavian.
Jerome> What is the rationale behind the decision that "a" would be equal to
Jerome> but not equal to "ä" ?
That's just how things work here :)
Anyway, the right way to fix this is to change the name of the latin1
character set to latin1_se and create a new character set latin1_en
The current plan is to do this in MySQL 4.0
We should not normally change the order of an existing character set
as this means that all tables that uses the old character set may