Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > On Tue, Sep 02, 2008 at 04:46:16PM +0300, Peter Eisentraut wrote: >> >While it's true POSIX locales don't handle this, other collation >> >libraries do and we should support them if the user wants.
I think that's backwards. We have to go with the lowest common denominator functionality of those libraries if we're going to be portable. As long as it's a superset of the SQL standard functionality. If we support features of some of them that can't be emulated with others then users end up with SQL code that will only work on some builds and not others. That might be worth it for some features but I'm not sure this is one. > Well, yes. Accents and case are attributes of a character. (I'm using > the unicode model here). So, to do a case insensetive match you take > the characters, strip the attributes and then do the comparison. There > are specialised routines which handle the denormalisation of the string > for you so in theory you could even get specific about which accents > you ignore. In practice I don't think people do that. I don't think composable unicode characters are really about collations. I think it had more to do with representing glyphs in UTF32 before they gave up on that. Does anyone still use composable characters? Note that we don't currently support composable characters at all. I'm not sure if that's a "nobody really cares" issue or a bug we should aim to fix with real collation support. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
