| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
| Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add PRODUCT() aggregate function |
| Date: | 2026-09-11 02:31:39 |
| Message-ID: | 948456.1789093899@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> writes:
> In my currently proposed patch (
> https://www.postgresql.org/message-id/CAM2+6=VS=fSKxfimW6Th9iu_xjbxOEAKg4eYwaa=SMg3X8pHaQ@mail.gmail.com)
> the ON EMPTY value is strictly returned only when there are zero input
> rows. Rows containing NULL are treated as valid rows and do not trigger the ON
> EMPTY clause.
[ ... not having read the patch ... ] There is a critical distinction
here between strict and non-strict aggregates. My interpretation of
how this should work is that ON EMPTY should trigger if zero rows were
fed to the aggregate's transition function. A row containing NULL is
valid input if the transition function is non-strict, otherwise it is
not.
What I gather from Vik's comments is that the SQL committee only
formalized the behavior for strict aggregates (since both PRODUCT
and SUM ignore nulls). So we're somewhat out on a limb here for
the non-strict case, but I think we have to define that one as
being "null inputs count as inputs".
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-09-11 02:32:34 | Re: Fix failing assert in deferred constraint trigger |
| Previous Message | Xuneng Zhou | 2026-09-11 02:24:30 | Re: Reject WAIT FOR earlier in transaction-snapshot mode |