Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq