Re: Confusing documentation of ordered-set aggregates?

I wrote:
> Florian Pflug <fgp@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