From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Subject: | Re: Combine function returning NULL unhandled? |
Date: | 2017-11-21 20:51:59 |
Message-ID: | CA+TgmoanqfkVaAO5kjQKyvcfUpCkF35P9=9rFjXjfTq-rzCc0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 20, 2017 at 10:36 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> The plain transition case contains:
> if (pergroupstate->transValueIsNull)
> {
> /*
> * Don't call a strict function with NULL inputs. Note it is
> * possible to get here despite the above tests, if the transfn is
> * strict *and* returned a NULL on a prior cycle. If that happens
> * we will propagate the NULL all the way to the end.
> */
> return;
> }
>
> how come similar logic is not present for combine functions? I don't see
> any checks preventing a combinefunc from returning NULL, nor do I see
> https://www.postgresql.org/docs/devel/static/sql-createaggregate.html
> spell out a requirement that that not be the case.
I don't know of a reason why that logic shouldn't be present for the
combine-function case as well. It seems like it should be pretty
straightforward to write a test that hits that case and watch it blow
up ... assuming it does, then I guess we should back-patch the
addition of that logic.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-11-21 20:55:23 | Re: [HACKERS] CLUSTER command progress monitor |
Previous Message | Tomas Vondra | 2017-11-21 20:42:37 | Re: [HACKERS] Custom compression methods |