I wrote:
> The same problem came up in connection with the "ordered set" aggregates
> that were added recently, and that patch implemented an interesting
> workaround: the final function for an OSA gets additional dummy arguments
> of the same type as the aggregate inputs. They are always passed as NULLs
> at runtime, and have no real value except if the aggregate is polymorphic
> --- but when it is, they provide a way to resolve the result type of a
> polymorphic final function, even if the state type is "internal" or
> otherwise non-polymorphic.
> I thought at the time that maybe we should offer this feature for regular
> aggregates as well as ordered-set ones, but didn't do anything about
> it because there hadn't been demand.
After sleeping on it, I'm convinced that this was an oversight that
we should fix before 9.4 ships. The code changes should be pretty
minimal; the executor in particular probably needs *less* code to
do this in a uniform way.
> One potential issue though is that if sample_final existed in both
> signatures it wouldn't be very clear which one got selected for the
> aggregate. Perhaps the best fix would be to invent a different
> CREATE AGGREGATE keyword for finalfns with extra arguments?
To be concrete: let's add a new boolean parameter with the semantics of
"final function takes extra dummy arguments" (default false). There would
need to be one for the separate moving-aggregate final function too,
of course.
The best naming idea I've got right now is "finalfunc_extra" and
"mfinalfunc_extra", but maybe somebody can do better?
regards, tom lane