Monty Taylor wrote: > Jay Pipes wrote: >> Perhaps the question to ask is, do we want the ability to do >> cross-schema collation switches? For example, a query which joins >> across multiple schemas with different collations. I'm pretty confident >> this is not a common occurrence at all. If we could impose a limit that >> queries across multiple schemas on a single server would be constrained >> to the server locale, then there wouldn't be a need to consider >> cross-schema collation switching, which would solve the problem, no? > > I wish. The problem with the collation libraries I've looked at so far > that don't require utf-16 like libicu does (like system libc or glib) is > that they except locale, and thus collation to be global. So any > switching within the lifespan of our process is a global operation.
Yes, and this is why the existing charset/collation library in MySQL exists... > Anybody know of a locale/collation lib that allows me to pass in a > locale as a param but also lets me play with utf8 natively? Nope. :( Thought: Strip out everything except UTF8. Keep collations for UTF8, drop everything else. Collations come into play when searching and sorting, whereas charsets come into play when storing and retrieving. Why not get rid of the overhead on storing and retrieving by going with UTF8 charset across the board and leave collation in for the time-being. Thought 2: Keep the current system because it works, until a library is found that is a) reentrant and thread-safe and b) small and flexible enough for our needs Thought 3: Take ICU, cut out UTF16 defaults and make it use UTF8 and cut out all edge cases that really aren't useful, and use that as the collation lib. Thought 4: Bitchslap whoever made setlocale() use a global variable ;) -jay _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
