Re: Fixed length data types issue

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