Joe, do you recall the reasoning for this code in parse_coerce.c?
if (targetTypeId == ANYOID || targetTypeId == ANYARRAYOID || targetTypeId == ANYELEMENTOID) { /* assume can_coerce_type verified that implicit coercion is okay */ /* NB: we do NOT want a RelabelType here */ return node; }
I see this in REL7_3_STABLE
else if (targetTypeId == ANYOID ||
targetTypeId == ANYARRAYOID)
{
/* assume can_coerce_type verified that implicit coercion is okay */
/* NB: we do NOT want a RelabelType here */
result = node;
}This was introduced here:
------------------------------------------
Revision 2.80 / (download) - annotate - [select for diffs] , Thu Aug 22 00:01:42 2002 UTC (14 months, 2 weeks ago) by tgl
Changes since 2.79: +42 -19 lines
Diff to previous 2.79
Add a bunch of pseudo-types to replace the behavior formerly associated
with OPAQUE, as per recent pghackers discussion. I still want to do some more work on the 'cstring' pseudo-type, but I'm going to commit the bulk of the changes now before the tree starts shifting under me ...
------------------------------------------
I think I just followed suit when adding ANYELEMENTOID.
This is AFAICT the only case where the parser will generate an expression tree that is not labeled with the same datatype expected by the next-higher operator. That is precisely the sort of mismatch that RelabelType was invented to avoid, and I'm afraid that we have broken some things by regressing on the explicit representation of type coercions.
The particular case that is causing me pain right now is that in my modified tree with support for cross-datatype index operations, cases involving anyarray_ops indexes are blowing up. That's because the visible input type of an indexed comparison isn't matching the declared righthand input type of any operator in the opclass. But RelabelType was put in to avoid a number of other problems that I can't recall in detail, so I am suspicious that this shortcut breaks other things too.
I think that the reason we did this was to allow get_fn_expr_argtype() to see the unrelabeled datatype of the input to an anyarray/anyelement- accepting function. Couldn't we fix that locally in that function instead of breaking a system-wide convention? I'm thinking that we could simply make that function "burrow down" through any RelabelTypes for any/anyarray/anyelement.
Does the RelabelType keep a record of what was relabeled (I presume from your description above it does)? The original code above predates get_fn_expr_argtype() I think, but it sounds like a reasonable approach to me.
Joe
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
