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

From Tom Lane
Subject Re: BUG #17088: FailedAssertion in prepagg.c
Date
Msg-id 1911540.1625694972@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17088: FailedAssertion in prepagg.c  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: BUG #17088: FailedAssertion in prepagg.c  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-bugs
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  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.

Fair enough.  This is the kind of design choice that can be worth
revisiting later; but if the conclusion is still the same, fine with me.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: BUG #17088: FailedAssertion in prepagg.c
Next
From: PG Bug reporting form
Date:
Subject: BUG #17093: invalid primary checkpoint record