Re: Teach predtest about IS [NOT] <boolean> proofs

James Coleman <jtc331(at)gmail(dot)com> writes:
> Attached is a patch that solves that issue. It also teaches predtest about
> quite a few more cases involving BooleanTest expressions (e.g., how they
> relate to NullTest expressions). One thing I could imagine being an
> objection is that not all of these warrant cycles in planning. If that
> turns out to be the case there's not a particularly clear line in my mind
> about where to draw that line.

I don't have an objection in principle to adding more smarts to
predtest.c. However, we should be wary of slowing down cases where
no BooleanTests are present to be optimized. I wonder if it could
help to use a switch on nodeTag rather than a series of if(IsA())
tests. (I'd be inclined to rewrite the inner if-then-else chains
as switches too, really. You get some benefit from the compiler
noticing whether you've covered all the enum values.)

I note you've actively broken the function's ability to cope with
NULL input pointers. Maybe we don't need it to, but I'm not going
to accept a patch that just side-swipes that case without any
justification.

Another way in which the patch needs more effort is that you've
not bothered to update the large comment block atop the function.
Perhaps, rather than hoping people will notice comments that are
potentially offscreen from what they're modifying, we should relocate
those comment paras to be adjacent to the relevant parts of the
function?

I've not gone through the patch in detail to see whether I believe
the proposed proof rules. It would help to have more comments
justifying them.

> As noted in a TODO in the patch itself, I think it may be worth refactoring
> the test_predtest module to run the "x, y" case as well as the "y, x" case
> with a single call so as to eliminate a lot of repetition in
> clause/expression test cases. If reviewers agree that's desirable, then I
> could do that as a precursor.

I think that's actively undesirable. It is not typically the case that
a proof rule for A => B also works in the other direction, so this would
encourage wasting cycles in the tests. I fear it might also cause
confusion about which direction a proof rule is supposed to work in.

regards, tom lane