From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Wrong results with grouping sets |
Date: | 2024-09-04 01:16:39 |
Message-ID: | CAMbWs49Yj3hz4uBA3hsCYHth0uEzfYbXJB+ONvQMJr+TapnFEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 6, 2024 at 4:17 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> I fixed this issue in v13 by performing the replacement of GROUP Vars
> after we've done with expression preprocessing on targetlist and
> havingQual. An ensuing effect of this approach is that a HAVING
> clause may contain expressions that are not fully preprocessed if they
> are part of grouping items. This is not an issue as long as the
> clause remains in HAVING. But if the clause is moved or copied into
> WHERE, we need to re-preprocess these expressions. Please see the
> attached for the changes.
I'm seeking the possibility to push 0001 and 0002 sometime this month.
Please let me know if anyone thinks this is unreasonable.
For 0003, it might be extended to remove all no-op PHVs except those
that are serving to isolate subexpressions, not only the PHVs used to
carry the nullingrel bit that represents the grouping step. There is
a separate thread for it [1].
[1] https://postgr.es/m/CAMbWs48biJp-vof82PNP_LzzFkURh0W+RKt4phoML-MyYavgdg@mail.gmail.com
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-09-04 01:25:17 | Re: Typos in the code and README |
Previous Message | Michael Paquier | 2024-09-04 00:40:01 | Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points |