On Mon, Jan 18, 2016 at 10:32 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 18 January 2016 at 16:44, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Sun, Jan 17, 2016 at 9:26 PM, David Rowley >> <david.row...@2ndquadrant.com> wrote: >> > hmm, so wouldn't that mean that the transition function would need to >> > (for >> > each input tuple): >> > >> > 1. Parse that StringInfo into tokens. >> > 2. Create a new aggregate state object. >> > 3. Populate the new aggregate state based on the tokenised StringInfo, >> > this >> > would perhaps require that various *_in() functions are called on each >> > token. >> > 4. Add the new tuple to the aggregate state. >> > 5. Build a new StringInfo based on the aggregate state modified in 4. >> > >> > ? >> >> I don't really know what you mean by parse the StringInfo into tokens. >> The whole point of the expanded-object interface is to be able to keep >> things in an expanded internal form so that you *don't* have to >> repeatedly construct and deconstruct internal data structures. > > > That was a response to Haribabu proposal, although perhaps I misunderstood > that. However I'm not sure how a PolyNumAggState could be converted to a > string and back again without doing any string parsing.
I just thought like direct mapping of the structure with text pointer. something like the below. result = PG_ARGISNULL(0) ? NULL : (text *) PG_GETARG_POINTER(0); state = (PolyNumAggState *)VARDATA(result); To handle the big-endian or little-endian, we may need some extra changes. Instead of adding 3 new columns to the pg_aggregate catalog table to handle the internal types, either something like the above to handle the internal types or some other way is better IMO. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers