Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Attached is a patch that fixes that test case. I'm not very familiar
> with that piece of code, though, and I have a sneaking suspicion that
> the patch is either not general enough, there may be other places where
> we should ignore relabel nodes, or it brakes something else.
If we were going to go this route, we'd need to uniformly make the
equivclass.c code strip RelabelType from *all* expressions it deals
with. Which might be a reasonable thing to do, since it always
considers their types to be the declared input types of the operators,
anyway. But it's a bigger patch than you have here.
I'm a bit annoyed with the idea because I had hoped to move in the
direction of getting rid of all the ad hoc RelabelType-stripping that
the planner does in various places. A lot of it is pretty darn
questionable from a semantic standpoint. However, because equivclass.c
is only worried about opfamily semantics, any RelabelTypes on the input
expressions don't matter, and so that objection doesn't apply.
The basic reason that there's a problem here is that the parser is
playing fast and loose by generating ORDER BY information that cites
"text < text" as the sort operator but applies it to a bare varchar
Var node. So I thought about a Plan B of changing the parser to put
a correct RelabelType on the sort key. I'm not sure of all the
implications of that, though, and you could argue that it's an
initdb-forcing change (because stored rules involving ORDER BY on
varchar columns would need to change to work right). Seems a bit
late in the 8.3 cycle for that.
I guess the right answer is to fix equivclass.c to strip RelabelTypes,
and hope to maybe take that out again someday when all this gets cleaned
up.
Comments?
regards, tom lane
