On Mon, Jan 18, 2016 at 10:32 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 18 January 2016 at 16:44, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Sun, Jan 17, 2016 at 9:26 PM, David Rowley
>> <david.rowley@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