| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jesse Zhang <sbjesse(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Denis Smirnov <sd(at)arenadata(dot)io>, Soumyadeep Chakraborty <sochakraborty(at)pivotal(dot)io> |
| Subject: | Re: Properly mark NULL returns in numeric aggregates |
| Date: | 2020-04-10 22:59:47 |
| Message-ID: | 12009.1586559587@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jesse Zhang <sbjesse(at)gmail(dot)com> writes:
> 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?).
They can't be strict because the initial iteration needs to produce
something from a null state and non-null input. nodeAgg's default
behavior won't work for those because nodeAgg doesn't know how to
copy a value of type "internal".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Morton | 2020-04-10 23:10:54 | Re: Support for DATETIMEOFFSET |
| Previous Message | Tom Lane | 2020-04-10 22:48:32 | Re: spin_delay() for ARM |