From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 02:08:42 |
Message-ID: | CAKU4AWoE+QpHbV_tEyGaz_uxvffJnbHuFRK2fXmfs_bj2fKWww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Aug 21, 2020 at 5:51 AM Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
wrote:
> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> Tom> As a stopgap measure, I think what we have to do is teach
> Tom> check_output_expressions that subquery output columns are unsafe
> Tom> to reference if they are not listed in all grouping sets (do I
> Tom> have that condition right?).
>
> Unless I'm missing something, it should be safe to reference output
> columns that are not mentioned in any grouping set,
I think such columns usually are aggregation expr, If we want to push down
a qual which reference to an aggregation expr, we have to push down
to having cause, However I am not sure such pushing down really helps.
> or which are
> mentioned in all grouping sets (after all expansions);
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-08-21 02:44:12 | Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS |
Previous Message | Andy Fan | 2020-08-21 01:19:57 | Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS |