I wrote:
> Florian Pflug <f...@phlo.org> writes:
>> array_agg(), for example, also has a result type that is
>> determined by the argument type, yet it's final function doesn't take an
>> argument of type anyelement, even though it returns anyarray.
> Yeah. So it's a complete leap of faith on the type system's part that
> this function is an appropriate final function for array_agg(). I'm
> not sure offhand if CREATE AGGREGATE would even allow this combination
> to be created, or if it only works because we manually jammed those rows
> into the catalogs at initdb time. But it would certainly be safer if
> CREATE AGGREGATE *didn't* allow it.
Actually, after a little bit of experimentation, the irreproducible
manual catalog hack is the very existence of array_agg_finalfn().
If you try to reproduce it via CREATE FUNCTION, the system will object:
regression=# create function foo(internal) returns anyarray as
regression-# 'array_agg_finalfn' language internal;
ERROR: cannot determine result data type
DETAIL: A function returning a polymorphic type must have at least one
polymorphic argument.
So what the ordered-set-aggregate patch has done is introduce a principled
way to define polymorphic aggregates with non-polymorphic state types,
something we didn't have before.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
