Re: BUG #17088: FailedAssertion in prepagg.c

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: BUG #17088: FailedAssertion in prepagg.c
Дата
Msg-id 875yxlrf5x.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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17092: SELECT using LIMIT clause without ORDER BY fails when parallel query is on
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17088: FailedAssertion in prepagg.c