On Jan10, 2014, at 15:49 , Tom Lane <t...@sss.pgh.pa.us> wrote:
> Florian Pflug <f...@phlo.org> writes:
>> Looking at the code it seems that for quite a few existing aggregates,
>> the state remains NULL until the first non-NULL input is processed. But
>> that doesn't hurt much - those aggregates can remain as they are until
>> someone wants to add an inverse transfer function. Once that happens,
>> there's a choice between living with needless rescans on trailing NULL
>> inputs or changing the state type.
> Also, it might be reasonable for both the regular and the inverse
> transition functions to be strict.  If a null entering the window
> does not matter, then a null exiting the window doesn't either, no?

That's not true, I think, unless we're special-casing strict transition
functions somewhere. AFAICS, an aggregate with a strict transition function
will produce the state NULL whenever any of the inputs was NULL, i.e. we won't
ever transition out of the NULL state once we got there. The inverse
transition function, however, would *have* to be able to transition away
from the NULL state, which requires it to be non-strict. Otherwise, how would
the state aver become non-NULL after the last NULL input leaves the window?

best regards,
Florian Pflug

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to