Florian Pflug <fgp@phlo.org> writes:
> On Apr11, 2014, at 17:09 , Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Basically, this comes down to a design judgment call, and my judgment
>> is differing from yours. In the absence of opinions from others,
>> I'm going to do it my way.
> Ok. Are you going to do the necessary changes, or shall I? I'm happy to
> leave it to you, but if you lack the time I can try to find some.
Nah, I'm happy to do the work, since it's me insisting on changing it.
>> Tell me about the special case here again? Should we revisit the issue?
> ...
> I don't feel too strongly either way on this one - I initially implemented the
> exception because I noticed that the NULL handling of some aggregates was
> broken otherwise, and it seemed simpler to fix this in one place than going
> over all the aggregates separately. OTOH, when I wrote the docs, I noticed
> how hard it was to describe the behaviour accurately, which made me like it
> less and less. And Dean wasn't happy with it at all, so that finally settled it.
Yeah, if you can't document the design nicely, it's probably not a good
idea :-(. Thanks for the summary.
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.
regards, tom lane