Re: The Future of Aggregation

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Uh, this also requires serialization and deserialization of non-
>> finalized transition state, no?

> A bunch of this stuff does, but I recently had a Brilliant Insight: we
> don't need to add a new method for serializing and deserializing
> transition functions. We can already do that: to serialize an
> aggregate transition state, you run it through the typoutput (or
> typsend) function and to deserialize it, you run it through the
> typinput (or typreceive) function. The only problem is that we have
> some aggregate functions that use an internal type. Those could,
> however, be changed: we could invent new types for each aggregate that
> uses a distinctive internal representation, rather than lumping it all
> under internal, and then give those types real input and output
> functions. That way, we don't really need to invent anything new
> here.

Yeah. Now, there are reasons why some of those aggregates are using
"internal" and not, say, "bytea": they want the core aggregate logic to be
just passing a pointer around and not trying to copy the aggregate's
actual state value. However, I have been wondering whether the "expanded
objects" stuff I did recently could provide a more principled way to do
that kind of thing.

regards, tom lane