Re: SQL99 ARRAY support proposal

Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> It would take some hackery to propagate the destination type down into
>> the ARRAY[] before the latter's type resolution is done, but at least
>> it'd be a quite localized hack.

> OK -- I'll try to make that work. I presume that in the non-specified
> case "ARRAY[1,2,3]" I should use something similar to UNION's resolution
> rules?

Yeah, that'd make sense to me.

>>> [...lots of good ideas regarding generalizing array operations...]

> I played with generalizing array functions a bit for plr and ran into
> some problems (which I can't specifically recall at the moment), but
> clearly that's the way to go. I'll start playing with your suggestions
> in C code, and report back for more feedback as it solidifies.

It'd be useful if you can reconstruct what problems you ran into.

After more thought I'm thinking that we should specify these pseudotypes
like so: a given set of actual operand types matches an
operator/function whose definition uses ANYARRAY or ANYELEMENT only if
the same element type is involved at all positions. Thus in
ANYARRAY = ANYARRAY
the left and right operands must be the same array type (so we preserve
the existing parse-time check, but we only need one pg_operator entry
to do it). For
ANYARRAY || ANYELEMENT
we get the desired behavior. And there are some other interesting
possibilities: for example, a function could be declared
foo(ANY, ANYELEMENT, ANYELEMENT)
which would mean that it takes any three datatypes, but the second
and third arguments have to be the same datatype.

If we run into limitations of this scheme, it could be generalized
further by adding pseudotypes ANYARRAY2 and ANYELEMENT2 that have
the same restriction among themselves, but are independent of
ANYARRAY/ANYELEMENT. Then for example
foo(ANYELEMENT, ANYELEMENT, ANYELEMENT2, ANYELEMENT2)
takes four params that can be anything so long as the first two are
the same datatype and the second two are also the same datatype (but
possibly a different type from the first two). And you could add
ANYARRAY3, etc, till you got bored. But I'd not bother with this
until someone showed a concrete need for it. At the moment, the
useful examples I can think of don't need more than one "free variable"
in their set of argument datatypes.

regards, tom lane