Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type' - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'
Date
Msg-id 28839.1398461182@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'  (Tomas Vondra <tv@fuzzy.cz>)
Responses Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'
List pgsql-hackers
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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Expression indexes ignore typmod of expression
Next
From: Andres Freund
Date:
Subject: Re: Expression indexes ignore typmod of expression