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/ ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
