On Wed, 2009-11-25 at 15:59 -0800, Jeff Davis wrote:
> > My operator-class-fu is insufficient to render judgment on this point.
> > I think the thing to do is look at a bunch of non-built-in opclasses
> > and check for POLA violations.
>
> Ok, I'll consider this more.
In cases where the operator class type is different from the search
operator's operands' types, one of the following is usually true:
* There is a binary cast from the opclass type (same as expression
type) to the search operator's operands' types, or it is otherwise
compatible (e.g. ANYARRAY).
* There is a candidate function that's a better match (e.g. there may
be an =(int8, int8) on int2_ops, but there's also =(int2, int2)).
* The left and right operand types are different, and therefore do not
work with operator exclusion constraints anyway (e.g. full text search
@@).
After installing all contrib modules, plus my period module, and
postgis, there appear to be no instances that violate these assumptions
(according to a join query and some manual testing). In theory there
could be, however.
It's kind of ugly to make it work, and a challenge to test it, so for
now I'll only accept operators returned by compatible_oper(). If you
disagree, I can make it work.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
