Re: Properly mark NULL returns in numeric aggregates - Mailing list pgsql-hackers

From Jesse Zhang
Subject Re: Properly mark NULL returns in numeric aggregates
Date
Msg-id CAGf+fX7bU4qWuNswP9VM-DZmUR2HzeRSYcJZj6uLpmw9wDhS=g@mail.gmail.com
Whole thread Raw
In response to Re: Properly mark NULL returns in numeric aggregates  (Andres Freund <andres@anarazel.de>)
Responses Re: Properly mark NULL returns in numeric aggregates  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi Andres,

On Fri, Apr 10, 2020 at 12:14 PM Andres Freund <andres@anarazel.de> wrote:
>
> Shouldn't these just be marked as strict?
>

Are you suggesting that because none of the corresponding trans
functions (int8_avg_accum, int2_accum, and friends) ever output NULL?
That's what we thought, but then I realized that an input to a comebine
function is not necessarily an output from a trans function invocation:
for example, when there is a "FILTER (WHERE ...)" clause that filters
out every tuple in a group, the partial aggregate might just throw a
NULL state for the final aggregate to combine.

On the other hand, we examined the corresponding final functions
(numeric_stddev_pop and friends), they all seem to carefully treat a
NULL trans value the same as a "zero input" (as in, state.N == 0 &&
state.NaNcount ==0). That does suggest to me that it should be fine to
declare those combine functions as strict (barring the restriction that
they should not be STRICT, anybody remembers why?).

Cheers,
Jesse and Deep



pgsql-hackers by date:

Previous
From: Alexandra Wang
Date:
Subject: Re: Report error position in partition bound check
Next
From: Tom Lane
Date:
Subject: Re: spin_delay() for ARM