On Fri, Sep 01, 2006 at 12:40:53PM +0200, Stefan Kaltenbrunner wrote: > heh if this is a request for a wishlist then I would suggest that we > should finally tackle one of the things most databases are doing better > then we (including MySQL) - that is better charset/locale/collate support. > especially for new users or users converting from other database this is > one of the major stumbling blocks (at least as seen on irc regulary) Yeah well, I got reasonably far on that. To the point of being able to have different collations on different columns, creating indexes with different collations and having collation-sensetive comparisons: http://archives.postgresql.org/pgsql-hackers/2005-12/msg01121.php Where I got stuck is teaching the planner how to use the collation info to produce appropriate plans. There wasn't a lot of feedback on the patch itself, so I didn't know how to proceed. I don't have time for it anymore but if someone wants to pick it up and run with it... Note however that it's not easy, there are a number of related issues which need to be solved at the same time: Supporting SORTFUNC_LT/GT is going to get much harder, but there no idea as to how much it's used anyway: http://archives.postgresql.org/pgsql-hackers/2005-12/msg01154.php The concept of "operator class" needs to be expanded into something more general, into something that's actually describes the type, rather than just how btrees work. Do we want to keep relying on the system libraries for collation, or do we want to use a cross-platform library like ICU or do we want to create our own collation library? Have a nice day, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
