Heikki Linnakangas <hlinnakangas@xxxxxxxxxx> writes: > We should do this automatically. Or am I missing something? Yes. This is not equality. > ALTER OPERATOR FAMILY integer_ops USING btree ADD > OPERATOR 3 <@ (int4, int4range), > FUNCTION 1 btint4rangecmp(int4, int4range); That will break approximately everything in sight, starting with the planner's opinion of what equality is. There is *way* too much stuff that knows the semantics of btree opclasses for us to start jamming random operators into them, even if this seemed to work in trivial testing. (See the last section of src/backend/access/nbtree/README to just scratch the surface of the assumptions this breaks.) It's possible that for constant ranges we could have the planner expand "intcol <@ 'x,y'::int4range" into "intcol between x and y", using something similar to the index LIKE optimization (ie, the "special operator" stuff in indxpath.c). I'd like to find a way to make that type of optimization pluggable, though --- the existing approach of hard-wiring knowledge into indxpath.c has never been anything but a kluge, and it definitely doesn't scale as-is to anything except built-in types and operators. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
