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.