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.