| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | malis(at)pgrust(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19619: WHERE scale(n) = 1 pushed past GROUP BY / window PARTITION BY, wrong COUNT |
| Date: | 2026-08-14 18:51:03 |
| Message-ID: | 3777654.1786733463@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> Tom's view on the HAVING form was that the query is ill-posed.
> The group's representative among equal numerics is unspecified, so
> HAVING scale(c) = 1 after grouping is not well defined.
> https://postgr.es/m/1738062.1784927903@sss.pgh.pa.us
Yeah. I'd be more excited about doing something about this if we'd
required opclasses to say whether their equality operator is image
equality or something weaker. But that was never designed into the
system, and retrofitting it now would be a mess. Since the only
benefit would be to queries that are arguably wrong anyway, it's
difficult to justify the effort.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-08-14 19:11:38 | Re: BUG #19449: Massive performance degradation for complex query on Postgres 16+ (few seconds -> multiple hours) |
| Previous Message | Andrey Rachitskiy | 2026-08-14 18:30:17 | Re: BUG #19619: WHERE scale(n) = 1 pushed past GROUP BY / window PARTITION BY, wrong COUNT |