Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'

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