Re: Using multi-locale support in glibc

Martijn van Oosterhout <kleptog@svana.org> writes:
> Do we have some platforms that don't have any multi-language support? I
> mean, we don't have a complete thread library but a wrapper around the
> ones used on the platform. Couldn't we make a similar wrapper that used
> glibc if it was available, windows native if it's available, etc...

> That way we conform to the platform rather than a version of the
> unicode collating set that postgresql happens to ship with it.

That seems likely to be the worst of all possible worlds :-(.  As to
the first point, our problem with the standard locale support is that
(a) it doesn't conveniently/cheaply support use of multiple locales per
program, and (b) it fails to expose (portably) information that we need
such as the character set assumed by a locale setting.  A wrapper around
that might hide the convenience problem, but not the performance problem
and definitely not the hidden-information problem.  As to the second
point, our experience with similar issues in the timezone library says
that platform-dependent behavior is the last thing we want.

I think we're going to end up doing just what we did with timezones,
ie, create our own library --- hopefully based on someone else's work
rather than rolled from scratch, but we'll feel free to whack the API
around until we like it.  No one's quite had the stomach to do that
yet though ... in part I suppose we're hoping a good library will drop
into our laps.

(The reason thread support is a poor analogy is that we don't actually
care about threads; we only support them to the extent the platform
wants us to.  The requirements for locale and timezones are driven in
the other direction, ie, we need more than most platforms are willing
to give.)
        regards, tom lane