On 25.4.2014 23:26, Tom Lane wrote:
> Tomas Vondra <tv@fuzzy.cz> writes:
>> On 23.4.2014 16:07, Tom Lane wrote:
>>> 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.
>
>> Do we really need a separate parameter for this? Couldn't this be
>> decided simply using the signature of the final function? Either
>> it has a single parameter (current behavior), or it has the same
>> parameters as the state transition function (new behavior).
>
> The problem is that the CREATE AGGREGATE syntax only specifies the
> name of the final function, not its argument list, so you have to
> make an assumption about the argument list in order to look up the
> final function in the first place.
>
> I did consider the idea of looking for both signatures and using
> whatever we find, but that seems fairly dangerous: the same CREATE
> AGGREGATE command could give different results depending on what
> versions of the final function happen to exist. This would create an
> ordering hazard that pg_dump could not reliably cope with, for
> example.
Yeah. And it wouldn't be clear which function to use in case two
suitable functions (with different signatures) exist. So I guess this
actually requires a parameter.
I'd vote for "finalfunc_extra" - can't think of a better name, and I'm
not sure what the "m" in "mfinalfunc_extra" stands for.
regards
Tomas