| From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add PRODUCT() aggregate function |
| Date: | 2026-06-23 11:02:34 |
| Message-ID: | 456004d3-b296-4946-b413-1fdda7476e29@uni-muenster.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Jeevan
On 23/06/2026 10:37, Dean Rasheed wrote:
> On Tue, 23 Jun 2026 at 08:49, Jeevan Chalke
> <jeevan(dot)chalke(at)enterprisedb(dot)com> wrote:
>> PRODUCT() returns the product of all non-null input values. It is defined for
>> int2, int4, int8, float4, float8 and numeric input, and always returns numeric.
> I don't think that you need to define it for all those types. I
> suspect that you could just define it for numeric and float8, and let
> implicit casting do the rest.
+1
I've tested the patch in many different scenarios and all results look
fine -- valgrind also didn't report anything :)
The test coverage is comprehensive! For the sake of completeness I'd add
numeric tests for NaN and Infitinty with positive numeric values in the
set, e.g:
postgres=# WITH j (v) AS (VALUES
('NaN'::numeric),('Infinity'::numeric),(3.14))
SELECT product(v) FROM j;
product
---------
NaN
(1 row)
Other than that and the point mentioned by Dean I have nothing to add at
this point.
Thanks for the patch.
Best, Jim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexandra Wang | 2026-06-23 11:02:41 | Re: Is there value in having optimizer stats for joins/foreignkeys? |
| Previous Message | Amit Kapila | 2026-06-23 10:39:23 | Re: doc: should pg_createsubscriber be grouped as a client application? |