Heikki Linnakangas wrote:
> have a default set per-database, per-table or per-column, but it's
> not a property of the actual value of a field. I think that the
> phrase "collation of a string" doesn't make sense.
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". 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?)
So "mathematically", you are right, the collation is a property of the
operation, not of the operands. But semantically, the operands do
carry the information of what collation order they would like to be
compared under, and if two pieces of data with different choices meet,
you need an override.
Incidentally, if you buy into that, this would also neatly solve the
problem of how to arrange for column-specific case conversion rules,
which SQL does not address at all.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
