On lör, 2011-04-23 at 13:17 -0400, Tom Lane wrote: > Should we have a TODO item to find a way of providing > platform-independent collation names?
This is a multifold problem. One issue is, if I'm looking for a locale for, say, "English, Canada", I will find it under "en_CA", if it exists at all. This is particularly important for users and application developers. I think we can do pretty well on that, since we're only supporting 3 platforms at the moment. Linux and Mac OS X, we understand, and Windows Vista and later also have locale names like "en-CA" (dash instead of underscore). (We haven't implemented support for that in initdb, and I don't have access to a sufficiently new Windows environment.) The other issue is, if I have a locale, I know what language it is for. We can do that for locales with standard names, as per above, and indeed initdb already does a little bit of that when picking the default text search configuration. I guess if we develop the text search/collation interaction further, we can just write down how we expect locales to be named, and if you violate that you get some stupid basic text search behavior. A more elaborate way would be to register the language in the pg_collation catalog separately, which would be almost equivalent to having a collation contain a reference to a text search configuration. (This could have other specialized applications: If I create a locale that sorts file names or XML specially, I might like a text search setup that also treats file names or XML specially.) The third issue is what naming scheme to recommend or to expect for alternative sort orders within a language. But I don't think we can really do much about that, nor do we need to. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
