Florian Pflug <f...@phlo.org> writes: > On Apr11, 2014, at 17:09 , Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers