Re: BUG #17088: FailedAssertion in prepagg.c - Mailing list pgsql-bugs

From Andrew Gierth
Subject Re: BUG #17088: FailedAssertion in prepagg.c
Date
Msg-id 87a6mxrggq.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: BUG #17088: FailedAssertion in prepagg.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17088: FailedAssertion in prepagg.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17088: FailedAssertion in prepagg.c
Next
From: Tom Lane
Date:
Subject: Re: BUG #17088: FailedAssertion in prepagg.c