Re: Confusing documentation of ordered-set aggregates?

I wrote:
> Florian Pflug <fgp(at)phlo(dot)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