"With per-column collation, you are being advocated to have two fields, one english_name, and one french_name, that have /the same content/, but are defined usi

"With per-column collation, you are being advocated to have two fields, one english_name, and one french_name, that have /the same content/, but are defined using a different collation, so that the ordering condition on them becomes language-dependent." I don't think that's the intention. Think of column collation as the "default" for that column, and you override it with the COLLATE clause. So if most of your ordering/range queries are based on american english, set the column collation to "en_US", and when you have a query that requires french ordering, then use the COLLATE clause by the column reference, and the ordering will change for french. I agree that SQL makes all of these things more confusing than they need to be, but supporting the standard for this concept has some value. "CREATE INDEX my_index ON my_table (a english_collation_ops);" I'm not sure if you're aware of this or not, but CREATE INDEX accepts a COLLATE clause in addition to the operator class. So the collation is kind of an extra parameter to the operator class (or something like that). So, it's not a question of capability, because I think the capability you want is readily there. However, if you are saying that it's more confusing than it needs to be, then I agree.