Re: Function accepting array of complex type

On Tue, Aug 25, 2015 at 6:21 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> This works:
>
> CREATE TYPE c AS (r float, i float);
> CREATE FUNCTION mag(c c) RETURNS float LANGUAGE sql AS $$
> SELECT sqrt(c.r^2 + c.i^2)
> $$;
> SELECT mag( (2.2, 2.2) );
> mag
> ------------------
> 3.11126983722081
>
> But this doesn't:
> CREATE FUNCTION magsum( c c[] ) RETURNS float LANGUAGE sql AS $$
> SELECT sum(sqrt(c.r^2 + c.i^2)) FROM unnest(c) c
> $$;
> SELECT magsum( array[row(2.1, 2.1), row(2.2,2.2)] );
> ERROR: function magsum(record[]) does not exist at character 8
>
> Presumably we're playing some games with resolving (...) into a complex
> type instead of a raw record; what would be involved with making that work
> for an array of a complex type? I don't see anything array-specific in
> parse_func.c, so I'm not sure what the path for this is...

​magsum( c c[] ) never gets a chance to coerce its argument because
array[row(...), row(...)]​

​beats it to the punch. SELECT mag( row(...) ) does see the untyped row
and seeing only a single function with parameter "c" coerces it to match.​
I'm not sure what can be done besides adding the cast to either the
array[]::c[] or to the individual items array[ row(...)::c ].

Hopefully the thought helps because I'm useless when it comes to the actual
code.

This does seem similar to how non-array literals are treated; though I'm
not sure if there are inferences (or node look-through) occurring in
literals that make some cases like this work while the corresponding
"unknown record" gets set in stone differently.

David J.​