On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Maybe a more general idea would be to invent "categories" of opclass
> members, where the only existing category is "index search qualifier",
> and these new knngist thingies are another, and maybe plus and minus for
> window function ranges are a third. But I'm not sure what you do if one
> operator can be in more than one category.
Well, if you were willing to change pg_amop so that the key was
(amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
just (amopfamily, amoplefttype, amoprighttype), the issue of what to
do if an operator can be in more than one category becomes moot. You
just specify the operator more than once if need be.
If you don't want the amopcategory to be part of the key, then you
just need to define it as a type that can handle multiple values yet
has a fast membership test. A character string of some type would be
flexible - you could use any single character as a category identifier
- but given that we don't expect many categories and we do want good
performance, it seems like an int4 used as a bitmap field would be
more appropriate.
I think the first approach is better, partly because it seems to lend
itself to a cleaner syntax for CREATE OPERATOR CLASS. Something like:
CREATE OPERATOR CLASS blah blah AS OPERATOR 3 &&, OPERATOR ORDER 15 <->;
...Robert
