Re: Add PRODUCT() aggregate function

From: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>
To: Vik Fearing <vik(at)postgresfriends(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add PRODUCT() aggregate function
Date: 2026-09-10 15:11:47
Message-ID: CAM2+6=Un-nsaw+cGnZPiLcWwUMAS4j48SYNhme6hBrXB8qFyKg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Vik,

On Thu, Sep 10, 2026 at 8:22 PM Vik Fearing <vik(at)postgresfriends(dot)org> wrote:

>
> On 23/06/2026 09:48, Jeevan Chalke wrote:
> >
> > * Naming. I went with PRODUCT(); other systems and discussions have used
> > names like PROD or MUL. Happy to change it if there is a consensus.
>
>
> Hi!
>
>
> It should be called PRODUCT

Thanks for seconding the aggregate name PRODUCT.

and it should accept the syntax
>
> PRODUCT(col, 1 ON EMPTY)
>
> for when there are no non-nulls in the input.
>
>
> This will be required by the next edition of the SQL standard. The exact
> value "1" is required by the standard, but I think we should allow any
> a_expr there.
>

Regarding the ON EMPTY clause, I have actually already proposed a patch for
that here:
https://www.postgresql.org/message-id/CAM2+6=VS=fSKxfimW6Th9iu_xjbxOEAKg4eYwaa=SMg3X8pHaQ@mail.gmail.com

It is designed to be applicable to any aggregate function. Note that in its
current form, the patch accepts any arbitrary expression (constant) for the
return value, rather than restricting it to a hard-coded literal.

I would really appreciate it if you could take a look at those changes and
share your reviews, feedback, or suggestions on that thread.
Thanks,

>
> --
>
> Vik Fearing
>
>

--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*

enterprisedb.com <https://www.enterprisedb.com>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2026-09-10 15:14:31 Re: Several issues with postgres_fdw stats import
Previous Message Pierre Ducroquet 2026-09-10 15:02:12 [RFC] Rework the executor opcodes to be position independent to improve JIT and interpreter performances