Re: BUG #17088: FailedAssertion in prepagg.c
От | Andrew Gierth |
---|---|
Тема | Re: BUG #17088: FailedAssertion in prepagg.c |
Дата | |
Msg-id | 87a6mxrggq.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: BUG #17088: FailedAssertion in prepagg.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17088: FailedAssertion in prepagg.c
|
Список | pgsql-bugs |
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> An alternative theory is that we should never have done anything Tom> at all to the argument tree of a GroupingFunc. Since it's not Tom> supposed to be evaluated, treating it as a target for expression Tom> preprocessing might be a mistake altogether. I wonder why its Tom> arguments aren't stored as sortgroupref indexes or the like. The arguments are stored as sortgrouprefs (the "refs" list) for actual use; the "args" list is only kept for the benefit of EXPLAIN and deparsing. A number of places in the planner have to explicitly avoid recursing into GroupingFunc->args when walking trees specifically because they are not evaluated. It looks to me like some places where that should have been checked for were missed. Looking into it. -- Andrew (irc:RhodiumToad)
В списке pgsql-bugs по дате отправления: