On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers