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
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' |
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 |