Re: SQL99 ARRAY support proposal

Joe Conway <mail(at)joeconway(dot)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:
> + *
> + * 1) All arguments declared ANY should have matching datatypes.
> + * 2) All arguments declared ANYARRAY should have matching datatypes.
> + * 3) All arguments declared ANYELEMENT should have matching datatypes.
> + * 4) If there are arguments of both ANYELEMENT and ANYARRAY, make sure
> + * the runtime scalar argument type is in fact the element type for
> + * the runtime array argument type.

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?

> + * 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.

regards, tom lane