Re: Making the planner more tolerant of implicit/explicit casts

I wrote:
> What I'm thinking about is modifying eval_const_expressions so that
> one of its responsibilities is to force CoercionForm fields to
> COERCE_DONTCARE in the output;

I fooled around with that approach for awhile and didn't like the
results, mainly because it caused EXPLAIN output to change in unpleasant
ways (ruleutils.c needs the CoercionForm info to format its output nicely).

However, on further reflection I realized that we could fix it just by
making equal() ignore CoercionForm fields altogether.  I remember having
considered that and shied away from it back when I first invented the
COERCE_DONTCARE hack, on the grounds that it would put too much semantic
awareness into equal().  However, we've long since abandoned the idea
that equal() should insist on full bitwise equality of nodes --- it's
ignored location fields for some time without ill effects, and there are
a number of other special cases in there too.  So as long as we're
willing to consider that equal() can mean just semantic equivalence of
two node trees, this can be fixed by removing code rather than adding
it, along the lines of the attached patch.

We could take the further step of removing the COERCE_DONTCARE enum
value altogether; the remaining uses are only to fill in CoercionForm
fields in nodes that the planner creates out of whole cloth, and now we
could make it fill in one of the more standard values instead.  I didn't
do that in the attached because it makes the patch longer but no more
enlightening (and in any case I don't think that change would be good to
back-patch).

I'm reasonably convinced that this is a good fix for HEAD, but am of two
minds whether to back-patch it or not.  The problem complained of in
bug #7598 may seem a bit narrow, but the real point is that whether you
write a cast explicitly or not shouldn't affect planning if the
semantics are the same.  This might well be a significant though
previously unrecognized performance issue, particularly for people who
use varchar columns heavily.

Thoughts?

			regards, tom lane