Re: Some TODO items for collations

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Some TODO items for collations
Date: 2011-04-25 00:39:56
Message-ID: 1303691996.5006.31.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Farina 2011-04-25 01:14:55 Re: fsync reliability
Previous Message Peter Eisentraut 2011-04-24 23:57:35 Re: Collation patch's handling of wcstombs/mbstowcs is sheerest fantasy