On Tue, 2008-12-02 at 15:08 +0100, Vladislav Vaintroub wrote:
> Lars-Erik, while I admit that is it a good job, except for taking slightly
> non-MBCS compliant handling of minSortChar.
Ahem, yes :) I forgot this one
> But, I do believe there are already too many workarounds in MySQLCollation
> The original problems are not documented anywhere and comments are missing
> , as usual. Thus I think for sake of portability, readability and other
> abilities a rewrite of this stuff using Mr. MySQL-Unicode( aka Bar) as
> consultant would be good. I bet almost all problems could be fixed using
> functions strings library already provides (this stuff might be not well
> documented as well, but it works) and there is no reasons to
> reinvent/reimplement stuff.
If Bar knows a better, and less complex way using the strings library,
then I am all for that! :)
> -First, why do we need computeKeyLength at all? What does it work around?
> -Which role does minSortChar play? Why are there attempts to trim it
> together with the blanks?
> -We don't we use charsetinfo->lengthsp() to trim blanks. Why not?
> -We use some ad-hoc technique to trim strings. Why?
> -why there are so many if (isBinary) in MySQLCollation?
> > -----Original Message-----
> > From: Lars-Erik.Bjork@stripped [mailto:Lars-Erik.Bjork@stripped]
> > Sent: Tuesday, December 02, 2008 2:21 PM
> > To: falcon@stripped
> > Subject: Please review fox for bug#34479
> > The fix is available at:
> > http://lists.mysql.com/commits/60379
> > The function MySQLCollation::computeKeyLength(...) is no longer
> > inlined,
> > because it would clutter the header file. Also, some of you (Vlad? :))
> > may have problems with using a couple of the CHARSET_INFO struct's
> > members 'directly', but this is already done elsewhere :)
> > Please enjoy! ;)
> > Best regards,
> > Lars-Erik
> > --
> > Falcon Storage Engine Mailing List
> > For list archives: http://lists.mysql.com/falcon
> > To unsubscribe: http://lists.mysql.com/falcon?unsub=1