Re: Add PRODUCT() aggregate function

From: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add PRODUCT() aggregate function
Date: 2026-09-11 01:13:42
Message-ID: CAMsGm5dCGJpu590LY+0Eqjryo0qAFKRh4rc3euGCGT_xdvgfdQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 10 Sept 2026 at 19:29, Vik Fearing <vik(at)postgresfriends(dot)org> wrote:

>
> On 10/09/2026 18:16, Tom Lane wrote:
> > Vik Fearing <vik(at)postgresfriends(dot)org> writes:
> >> It should be called PRODUCT and it should accept the syntax
> >> PRODUCT(col, 1 ON EMPTY)
> >> for when there are no non-nulls in the input.
> > Sigh. The committee really loves to invent randomly creative syntax,
> > don't they. At least this one won't force us to create any new
> > fully-reserved words.
>
>
> Yes. I tried to fight back on it but I was overruled.
>

Out of curiosity, was there any thought given to the idea that it should be
an attribute of the aggregate itself? The following seem to me to be pretty
hard to dispute: max -> -infinity; min -> infinity; sum -> 0; product -> 1;
string_agg -> ''; array_agg -> []. Of course there is legacy behaviour that
can't just be erased, but an option with just two choices defaulting to the
NULL result could handle that.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-09-11 01:21:29 Re: Add PRODUCT() aggregate function
Previous Message Fujii Masao 2026-09-11 00:54:13 Re: fixes for a few GUC descriptions