Re: SQL99 ARRAY support proposal

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