Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS

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

In response to

Responses

Browse pgsql-bugs by date

  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