| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Vik Fearing <vik(at)postgresfriends(dot)org> |
| Cc: | 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-10 23:46:50 |
| Message-ID: | 938904.1789084010@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Vik Fearing <vik(at)postgresfriends(dot)org> writes:
> On 10/09/2026 18:16, Tom Lane wrote:
>> I think that this may be trickier than it looks. You'd really want
>> that to act like a "direct" argument, ie evaluate once not once per
>> row.
> That's fair, but it isn't what happens for string_agg, for example,
> which can have a different separator per value.
Sure, but that's not the same thing. You can do something credible
with a separator-per-value in string_agg, but it's nonsense to suppose
that ON EMPTY is a per-row value. If it were per-row, which value
would you use? I assume it applies even if there are zero input rows,
not only if there are some inputs but they happen to all be null.
The committee is evidently choosing to sidestep the
how-many-evaluations question by insisting on a constant value,
which may well be sufficient for all real-world cases. If we want
it to be "any a_expr" though, we have to think about that.
> It's for both PRODUCT and SUM (1 and 0 respectively) and not generalized
> beyond that.
OK, at least the SUM case occurred to them ;-). But I think for
our purposes we definitely want to allow it for any aggregate.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2026-09-10 23:49:11 | Re: Race conditions in logical decoding |
| Previous Message | Amit Langote | 2026-09-10 23:41:21 | Re: PG19: two RI fast-path issues found while testing the batching revert |