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;
}
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.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
