Hi
After reading through the relevant parts of sytnax.sgml, create_aggregate.smgl
and xaggr.sgml, I think I understand how these work - they work exactly like
regular aggregates, except that some arguments are evaluated only once and
passed to the final function instead of the transition function. The whole
"ORDER BY" thing is just crazy syntax the standard mandates - a saner
alternative would have been
ordered_set_agg(direct1,...,directN, WITHIN(arg1,...,argM))
or something like that, right?
So whether "ORDER BY" implies any actual ordering is up to the ordered-set
aggregate's final function. Or at least that's what xaggr.sgml seems to say
Unlike the case for normal aggregates, the sorting of input rows for anordered-set aggregate is <emphasis>not</> done
behindthe scenes, but isthe responsibility of the aggregate's support functions.
but that seems to contradict syntax.sgml which says
The expressions in the <replaceable>order_by_clause</replaceable> areevaluated once per input row just like normal
aggregatearguments, sortedas per the <replaceable>order_by_clause</replaceable>'s requirements, andfed to the aggregate
functionas input arguments.
Also, xaggr.sgml has the following to explain why the NULLs are passed for all
aggregated arguments to the final function, instead of simply not passing them
at all
While the null values seem useless at first sight, they are important becausethey make it possible to include the data
typesof the aggregated input(s) inthe final function's signature, which may be necessary to resolve the outputtype of a
polymorphicaggregate.
Why do ordered-set aggregates required that, when plain aggregates are fine
without it? 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.
best regards,
Florian Pflug