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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'
Date: 2014-04-25 21:26:22
Message-ID: 28839.1398461182@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tomas Vondra <tv(at)fuzzy(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Augori 2014-04-25 23:26:08 Re: Unrecognized service
Previous Message Tomas Vondra 2014-04-25 21:16:01 Re: [GENERAL] aggregate returning anyarray and 'cannot determine result data type'

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-25 21:29:48 Re: Expression indexes ignore typmod of expression
Previous Message Tom Lane 2014-04-25 21:19:00 Re: Expression indexes ignore typmod of expression