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 875yxlrf5x.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:

 > Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
 >> 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.

 Tom> Hmm. Maybe it'd be better if the default behavior in
 Tom> expression_tree_walker/mutator did not include recursing into the
 Tom> args, then?

You'd think, but as I recall (I will re-check this to confirm) there
were more places where we _did_ need to recurse (especially during parse
analysis before we've matched up the sortgrouprefs), while most of the
places where recursion needed to be explicitly avoided already needed
special-case handling, so having the default the other way would likely
have required a special-case almost everywhere.

-- 
Andrew.



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17092: SELECT using LIMIT clause without ORDER BY fails when parallel query is on
Next
From: Tom Lane
Date:
Subject: Re: BUG #17088: FailedAssertion in prepagg.c