Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jun 16, 2016 at 6:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Meh. I think this is probably telling us that trying to repurpose Aggref
>> as the representation of a partial aggregate may have been mistaken.
> I don't mind if you feel the need to refactor this.
I'm not sure yet. What I think we need to work out first is exactly
how polymorphic parallel aggregates ought to identify which concrete
data types they are using. There were well-defined rules before,
but how do we adapt those to two levels of aggregate evaluation?
Are we hard-wiring an assumption that the aggregate transtype is the
same at both levels? What assumptions do we want to make about the
relationship of the data transfer type (the lower level's output type)
to the polymorphic input and trans types?
A key point here is that the way that polymorphic aggregate support
functions used to find out what they were doing is that we'd set up
dummy FuncExprs that would satisfy get_call_expr_argtype(). That
relied on the fact that the transfn and finalfn calls were specified
in a way that corresponded to legal SQL function calls. It's not
clear to me whether that statement still holds for parallelized
aggregates.
regards, tom lane