From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, pavelsivash(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS |
Date: | 2020-08-21 20:49:07 |
Message-ID: | 2018365.1598042947@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> subquery_planner isn't transferring HAVING clauses to WHERE if that
> would cross a nontrivial GROUPING SETS. It could in theory do so by
> inspecting whether the referenced columns are in all grouping sets or
> none, but currently the planner doesn't have any reason to compute that
> intersection and it would add quite a bit of complexity to that specific
> point in the code.
Hm. I see that computing that set is not really trivial. I'd supposed
that we probably had code to do it somewhere, but if we don't, I'm
disinclined to add it for this. So that leads to the conclusion that we
should just shut off push-down in this situation, as per attached quick
hack (no test case) patch.
> In this example, pushing the condition below the aggregate would be
> wrong anyway, no?
Agreed. I hadn't thought hard enough about the semantics, but if
"hundred" goes to null in a particular grouping set, so should
"abs(hundred)".
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
prevent-pushdown-with-grouping-sets.patch | text/x-diff | 1.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-08-21 20:54:58 | BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta |
Previous Message | PG Bug reporting form | 2020-08-21 14:20:53 | BUG #16588: Unable to delete database due to still connection |