| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> | 
| Cc: | guofenglinux(at)gmail(dot)com, andrew(at)tao11(dot)riddles(dot)org(dot)uk, michael(at)paquier(dot)xyz, cyg0810(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org | 
| Subject: | Re: BUG #17088: FailedAssertion in prepagg.c | 
| Date: | 2022-03-21 21:09:54 | 
| Message-ID: | 2319370.1647896994@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> At Fri, 9 Jul 2021 14:54:02 +0800, Richard Guo <guofenglinux(at)gmail(dot)com> wrote in 
>> Update the patch with comments and test cases.
> AFAICS the patch looks correct.  It works for the first example and
> the two from Tom.  I don't find other place that has the similar
> issue.
I'd been expecting Andrew to pick this up, but since he hasn't,
I took a look.
I concur that the core problem is that GroupingFunc has to be treated
almost exactly like Aggref, and here we have a couple of places that
didn't get that memo.  So it occurred to me to look for other places
that special-case Aggref and don't have parallel code for GroupingFunc,
and I found several:
expression_returns_set_walker
This isn't particularly hazardous, since the argument (probably?) can't
contain a SRF, but it still seems like it ought to treat the two node
types the same.
cost_qual_eval_walker
It's defaulting to charging the eval costs of the arguments, which is
flat wrong.  I made it charge one cpu_operator_cost instead.
ruleutils.c
Various places concerned with whether or not we need parens were
making the wrong choice, resulting in excess parens in pretty-printing
mode.  This is also just cosmetic, but still.
This looks good to me now, and I'll set about back-patching.
regards, tom lane
| Attachment | Content-Type | Size | 
|---|---|---|
| v2-0001-fix-oversights-in-GroupingFunc-handling.patch | text/x-diff | 7.7 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-03-21 22:23:30 | Re: BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded | 
| Previous Message | PG Bug reporting form | 2022-03-21 20:37:15 | BUG #17445: "ON CONFLICT" has different behaviors when its param is passed with prepared stmt or hard coded |