> > Face it, everything has locale support these day. PostgreSQL is one of
> > the few packages that even has it as an option to turn it off. Users of
> > binary packages of PostgreSQL are all invariably faced with locale
> > features. So it's not like sudden unasked-for locale support is going to
> > be a major shock.
>
> Certainly everyone would agree that "locale support" is desirable.
No. At least for Japanese, LC_COLLATE is not usefull at all. Let me
explain why. Japanese has three kind of characters: The first one is
called "Kanji", Scond one is "Hiragana". The last one is "Katakana".
Many pary of data stored in database are usually written in Kanji. The
problem is, Kanji is an ideogram and there is no algorithm to guess
the correct pronunciation for Kanji letters. The only solution for
this is add a separate column having Hiragana or Katakana letters
which represents the pronunciation for the Kanji column (Hiragana and
Kataka are phonogram). Sorting is also done by the additional
Hiragana/Katakan column, that can be done according to the code point
of Hiragana/Katakana. So no locale support (LC_COLLATE) is neccessary
at all for Japanese.
> Tatsuo has been one of the earliest and most vocal participants in
> design speculations on how to support the SQL9x concept of character
> sets and collations, which for purposes of long range planning seem to
> be synonymous with "locale" afaict.
>
> The question is whether and how to continue to extend the use of
> OS-supplied features to accomplish this support, with the severe
> restrictions (from an SQL9x pov) which come with the OS implementation.
In my opinion, with the SQL99 collate support, the current locale
support should be vanished.
--
Tatsuo Ishii