| 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*
| 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 |