Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS
| От | Andy Fan |
|---|---|
| Тема | Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS |
| Дата | |
| Msg-id | CAKU4AWoE+QpHbV_tEyGaz_uxvffJnbHuFRK2fXmfs_bj2fKWww@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
| Ответы |
Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS
|
| Список | pgsql-bugs |
On Fri, Aug 21, 2020 at 5:51 AM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-bugs по дате отправления: