Re: Constraint Type Coercion issue?

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> So, is this a real bug in constraints or does the problem lie somewhere
> else? Is it fixable?

Not readily. The problem is here:

* We must find a btree opclass that contains both operators, else the
* implication can't be determined. Also, the pred_op has to be of
* default subtype (implying left and right input datatypes are the
* same); otherwise it's unsafe to put the pred_const on the left side
* of the test. Also, the opclass must contain a suitable test
* operator matching the clause_const's type (which we take to mean
* that it has the same subtype as the original clause_operator).

The predtest code depends on btree operator classes to tell it the
semantics of comparisons, and the operator class infrastructure just
doesn't support making cross-type inferences very well. Given, say,
int8var <= int4const
we'd like to determine whether
int8var <= otherint4const
is implied (or refuted), but to do this we need to compare the two
int4 constants, for which we need the int4 vs int4 comparison operator,
which has no relationship whatever to the int8 operator class in which
we find the int8 <= int4 operators that are present in the clauses.

There are some related cases in btree index search startup that would
be nice to fix too.

I've been thinking about this off and on, and would like to solve it
in the 8.2 time frame, but it's not happening for 8.1. At a minimum
it'll require some significant changes in our concept of what an
operator class is. The half-jelled ideas I have involve inventing
families of operator classes, so that we could for instance represent
the idea that "int2_ops, int4_ops, and int8_ops are all compatible,
and you can get consistent results from any of these operators".
There are some related problems involving mergejoin and the ability
to deal with reverse-sort indexes that also need to be dealt with,
and seem to require extensions to the operator class concept.

regards, tom lane