Re: Locales and Encodings - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Locales and Encodings
Date
Msg-id 470FB1CB.1070603@phlo.org
Whole thread Raw
In response to Re: Locales and Encodings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> Am Freitag, 12. Oktober 2007 schrieb Gregory Stark:
>>> It would make Postgres inconsistent and less integrated with the rest of
>>> the OS. How do you explain that Postgres doesn't follow the system's
>>> configurations and the collations don't agree with the system collations?
> 
>> We already have our own encoding support (for better or worse), and I don't 
>> think having one's own locale support would be that much different.
> 
> Well, yes it would be, because encodings are pretty well standardized;
> there is not likely to be any user-visible difference between one
> platform's idea of UTF8 and another's.  This is very very far from being
> the case for locales.  See for instance the recent thread in which we
> found out that "en_US" locale has utterly different sort orders on
> Linux and OS X.

For me, this paragraph is more of in argument *in favour* of having our own 
locale support. At least for me, consistency between PG running on different 
platforms would bring more benefits than consistency between PG and the platform 
it runs on.

At the company I used to work for, we had all our databases running with 
encoding=utf-8 and locale=C, because I didn't want our applications to depend on 
platform-specific locale issues. Plus, some of the applications supported 
multiple languages, making a cluster-global locale unworkable anyway - a 
restriction which would go away if we went with ICU.

regards, Florian Pflug



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: First steps with 8.3 and autovacuum launcher
Next
From: Tom Lane
Date:
Subject: Re: First steps with 8.3 and autovacuum launcher