So in this case if argL or argR are functions or other expressions with unknown types it tries to figure out how to interpret them to produce the type it's looking for. In other words, what type those expressions are depends on what the expression expects. What would you do with "foo() IN (array[1,2])" if there are two functions called foo, one which returns an integer and one which returns an integer[] ?
Well, first off, it isn't now, nor has it ever been (to my knowledge), possible to overload a function with more than one return type. It also isn't possible to declare a polymorphic return type unless at least one argument is polymorphic (meaning there must be at least one argument), in which case the return type is absolutely deterministic at time of execution.
I'm not sure it's worth discussing this too much further, due to Tom's objection to the concept in general, but anyway...you should use the source. Starting with gram.y, we have this:
r_expr: row IN_P select_with_parens
{
SubLink *n = makeNode(SubLink);
n->subLinkType = ANY_SUBLINK;
n->lefthand = $1;
n->operName = makeList1(makeString("="));
n->subselect = $3;
$$ = (Node *)n;
}Here you can see that "IN" is actually transformed internally
to an "= ANY" SubLink node. In parse_expr.c you'll see (around line 518 in current sources) where the ANY SubLink is processed. Note that exprType() is used on the expressions in order to determine (recursively) the argument data types, so that the appropriate operator can be picked. Hence, if we *wanted* to know if exprType(right_expr) was an array of exprType(left_expr), we could.
One of these days I'm going to suggest doing away with the whole "unknown" concept and make function return types not part of the polymorphic signature. That would make a lot of the type system weirdness go away. But it would mean breaking with a lot of tradition.
That doesn't make too much sense either. Polymorphic return types were not possible prior to 7.4.
Joe
---------------------------(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
