Richard Guo <riguo@pivotal.io> writes:
> In this patch, we are trying to do the similar deduction, from
> non-equivalence
> clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> restrictions on f.
Uh, *what* restrictions on f()? In general the above equivalence
does not hold, at least not for any data type more complicated than
integers; and we do not have any semantic model for deciding
which functions it would be correct for.
One simple example to show what I'm talking about is that float8 zero
and minus zero are equal according to float8eq (assuming IEEE float
arithmetic); but they aren't equivalent for any function f() that is
sensitive to the sign or the text representation of the value.
The numeric data type likewise has values that are "equal" without
being identical for all purposes, eg 0.0 vs 0.000. Or consider
citext.
The existing planner deduction rules for equivalence classes are
carefully designed to ensure that we only generate derived clauses
using operators from the same operator class or family, so that
it's on the opclass author to ensure that the operators have consistent
semantics. I don't think we can extrapolate from that to any random
function that accepts the datatype.
regards, tom lane