Joe Conway <[EMAIL PROTECTED]> writes:+ * If ANY, ANYARRAY, or ANYELEMENT is used for a function's arguments or + * return type, make sure the runtime types are consistent with + * each other. The argument consistency rules are like so:
Hmm. I don't see why we should drag ANY into this --- it should just be a no-constraints placeholder, same as before. What's the gain from constraining it that you don't get from ANYELEMENT?
I was thinking of the case create function foo("any") returns "any" but I guess you're right, it can just as easily be create function foo(anyelement) returns anyelement
I'll pull the ANY stuff out.
+ * 5) If return type is ANYARRAY, no argument is ANYARRAY or ANYELEMENT, + * leave the return type as is. + * XXX should this case be rejected at the point of function creation?
Probably. This case could be handled just as well by declaring the output to be ANY, I'd think.
+ * 8) If return type is ANYELEMENT, no argument is ANYARRAY or ANYELEMENT + * leave the return type as is. + * XXX should this case be rejected at the point of function creation?
Likewise. The point of (this reinterpretation of) ANYARRAY and ANYELEMENT is to let the parser deduce the actual output type. If it's not going to be able to deduce anything, use ANY instead.
OK -- I'll take care of that too.
Thanks,
Joe
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
