Greg Stark wrote:
> 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