Tom Lane wrote:
> Joe Conway <mail@joeconway.com> 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
