On Tue, Jun 04, 2013 at 12:03:10PM +0200, Martin Pitt wrote:
> > (seems a pain for longer lived instances, where you would want it to
> > be carried across).
> I don't understand this -- if you run your entire server without
> locales, then a lot of stuff will not work; e. g. your cited
> postgresql bug, if you build a cloud instance without any locale and
> install postgresql in it, then your instance will not have any idea
> about correct collation, sorting, charsets, and so on. I'd think that
> on a server you ought to set the system locale to what you actually
> want, and then have your services use that, not some random locale
> from outside that someone happens to use on their workstation?
Well, collation in database servers is an interesting problem. MS SQL gets
this particularly wrong - attaching particular collations to the schema of
individual columns. I think Postgres does better than this, but if it's
dependent on the collation order of the locale that the server is started
in, that's still not great. But in any case, if postgres is dependent on
libc for collation implementation (which seems reasonable, all things
considered), I don't think we're doing a very good job today of making sure
the necessary locale data is available at the right time.
You shouldn't have to install language-pack-tr to be able to get a Turkish
collation order on your database server, for instance.
I'm not sure what the right fix for this is - maybe the postgres packages
should generate their own collation data from the locales package at install
or build time? Certainly, if you need a particular locale at package build
time, the portable way to handle this is to build it yourself and point at
the local copy; this might be the right answer wrt database servers at
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/