Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera
> <alvhe...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
