Martijn van Oosterhout <kleptog@svana.org> writes:
> Well yes, but given the number of possible locales, creating one class
> for each seems excessive. And each class would have to create 5
> operators (with underlying functions) and 1 comparitor function. Unless
> you could shortcut something like:
> CREATE OPERATOR CLASS ...
> OPERATOR 1 <(text,text,'en_US')
> ...
> FUNCTION 1 mycompare(text,text,'en_US')
> ...
> COLLATE en_us;
The thing that's still fairly unclear to me is whether the collation
information is attached to the operators/functions or to the data.
I recall there's been some discussion of sticking collation IDs into
individual text Datums, which is a completely different path than what
you are positing above. Does the SQL spec mandate one or the other of
these approaches? If it does, do we want to believe it? (The more I
read of SQL2003, the less impressed I get...)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
