On Wed, Sep 14, 2005 at 05:28:42PM -0400, Tom Lane wrote: > > To some extent, collate > > implies a sort of parameterised operator class... > > Hmm. But an index couldn't support more than one collation order > AFAICS. It'd probably make more sense to create operators and an > operator class for each collation you want to support; the mapping > to a call of a common support function would be embedded inside the > operator definition. Otherwise we have to pass around an additional > parameter through an awful lot of places...
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; Otherwise you end up with lots of functions which have be created on the fly as the user decides what collate orders he wants. Invoking SQL functions in the btree index create cycle doesn't seem efficient. You would have to come up with new names for the operators each time because the argument types are going to be the same. Although I guess you could call it OPERATOR(<en_us), it's not like people are going to use it directly. Maybe it should be that we allow users to specify three argument operators, and have an extra entry in the operator class which defines the extra argument to pass. It's not easy, like you say, there are a lot of places where an extra argument would need to be passed... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
pgpMc8fzZLktq.pgp
Description: PGP signature
