On Apr11, 2014, at 19:04 , Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It strikes me that your second point
>
>> 2) It allows strict aggregates whose state type and input type aren't
>> binary coercible to return NULL if all inputs were NULL without any
>> special coding. As it stands today, this doesn't work without some
>> kind of counter in the state, because the final function otherwise
>> won't know if there were non-NULL inputs or not. Aggregates whose state
>> and input types are binary coercible get around that by setting the
>> initial value to NULL while *still* being strict, and relying on the
>> state replacement behaviour of the aggregate machinery.
>
> could be addressed by the initfunc idea, but I'm still not sufficiently
> excited by that one. Given the problem with internal-type transition
> values, I think this could only win if there are cases where it would let
> us use a regular SQL type instead of internal for the transition value;
> and I'm not sure that there are many/any such cases.
Yes, the idea had come up at some point during the review discussion. I
agree that it's only worthwhile if it works for state type internal - though
I think there ought to be a way to allow that. We could for example simply
decree that the initfunc's first parameter must be of type internal if it's
return type is, and then just pass NULL for that parameter.
What I like about the initfunc idea is that it also naturally extends to
ordered-set aggregates, I think it'd be very useful for some possible
ordered-set aggregates to received their direct arguments beforehand and not
afterwards.
But that all seems largely orthogonal to the invtrans patch.
best regards,
Florian Pflug