Peter Eisentraut wrote:
The real problem is that the established method dividing up the locale
categories ignores both the technological and the linguistic reality.
In reality, all properties like lc_collate, lc_ctype, and lc_numeric
are dependent on the property "language of the text".
I don't buy that. lc_collate, lc_ctype and lc_numeric are certainly
related, but they're not a property of the "language of the text". For
example, imagine an employee database for an international company. When
a user wants to print out a sorted list of employees, the language of
the text in the database (name of an employee) is irrelevant. A german
user would like to see the names in different order than an
English-speaking user.
I've seen this in practice. Also, see:
http://www.unicode.org/unicode/reports/tr10/#Common_Misperceptions
for another example.
In general, it
doesn't make sense to sort a text by Spanish rules, downcase by Turkish
rules, and embed numbers using English punctuation. Of course you can
do all that, but it's generally not very useful and might give
inconsistent results. (For extra credit: how do you do
case-insensitive sorts with inconsistent lc_collate and lc_ctype
settings?)
Sure. Don't do that, that's just silly. But I don't see how that's relevant.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
