Horton

Re: Wrong results with grouping sets

Richard Guo <guofenglinux@gmail.com>

View thread
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-09-04T01:16:39Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove the RTE_GROUP RTE if we drop the groupClause

  2. Mark expressions nullable by grouping sets

  3. Introduce an RTE for the grouping step

On Tue, Aug 6, 2024 at 4:17 PM Richard Guo <guofenglinux@gmail.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