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+fX5FwjBUjA7WahGvX-OcqhjKB6d072eNa7RiFZ+0tG31Qg@mail.gmail.com
Whole thread Raw
In response to Re: Properly mark NULL returns in numeric aggregates  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Properly mark NULL returns in numeric aggregates  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Apr 10, 2020 at 3:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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

Ah, I think I get it. A copy must happen because the input is likely in
a shorter-lived memory context than the state, but nodeAgg's default
behavior of copying a by-value datum won't really copy the object
pointed to by the pointer wrapped in the datum of "internal" type, so we
defer to the combine function. Am I right? Then it follows kinda
naturally that those combine functions have been sloppy on arrival since
commit 11c8669c0cc .


Cheers,
Jesse



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Poll: are people okay with function/operator table redesign?
Next
From: Robert Haas
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?