Re: Lack of RelabelType is causing me pain

Tom Lane wrote:
> 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