On Thu, 2009-11-26 at 01:33 -0800, Jeff Davis wrote:
> Remaining issues:
> * represent operator IDs in catalog, rather than strategy numbers
Done, attached.
> * if someone thinks it's an issue, support search strategies that
> require binary-incompatible casts of the inputs
I've already solved the original problem involving ANYARRAY. If someone
comes up with a good use case, or provides me with a little more
guidance, I'll reconsider this problem again. Otherwise, I feel like I'm
solving a problem that doesn't exist (after all, none of the contrib
modules seem to have a problem with the current assumptions, nor does
postgis, nor does my PERIOD module). So, I'm considering this a
"non-issue" until further notice.
To summarize, the problem as I understand it is this:
You have two types, T1 and T2, and there's an implicit cast (with
function or with inout) from T1 to T2. And you have an opclass like:
CREATE OPERATOR CLASS t1_ops FOR TYPE t1
...
OPERATOR 17 %%(t2, t2)
...
And then you have an exclusion constraint like:
CREATE TABLE foo
(
a t1,
EXCLUDE (a t1_ops WITH %%)
);
What should the behavior be in the following two cases?
1. Only operator %%(t2, t2) exists.
2. Operator %%(t1, t1) and %%(t2, t2) exist.
If left unsolved, #1 results in an error because the operator requires
binary-incompatible coercion. #2 results in an error because %%(t1, t1)
is not in the opclass.
Arguably either one of them could succeed by finding %%(t2, t2) and
performing the appropriate conversion; but I think it's fair to just say
"the opclass is poorly defined".
Note that if the opclass is on type t2, you can simply cast "a" to t2
explicitly in the expression, like so:
EXCLUDE((a::t2) t2_ops WITH %%)
Regards,
Jeff Davis
