On Tue, Aug 25, 2015 at 6:21 PM, Jim Nasby <jim.na...@bluetreble.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.
