*To summarise,* the options we have to solve the limitation of the @>(anyarray , anyelement) where it produces the following error: operator does not exist: integer[] @> smallint
*Option 1: *Multiple Operators Have separate operators for every combination of datatypes instead of a single polymorphic definition (i.e int4[] @>> int8, int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric.) Drawback: High maintenance. *Option 2: *Explicit casting Where we compare the datatype of the 2 operands and cast with the appropriate datatype Drawback: figuring out the appropriate cast may require considerable computation *Option 3:* Unsafe Polymorphic datatypes This a little out there. But since @>(anyarray, anyelement) have to resolve to the same datatype. How about defining new datatypes without this constraint? Where we handle the datatypes ourselves? It would ve something like @>(unsafeAnyarray, unsafeAnyelement). Drawback: a lot of defensive programming has to be implemented to guard against any exception. *Another thing* Until this is settled, another thing I have to go through is performance testing. To provide evidence that all we did actually enhances the performance of the RI checks. How can I go about this? Best Regards, Mark Rofail
