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