On Sun, Apr 6, 2025 at 1:46 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > The parser, rewriter, and planner all have a bad habit of scribbling > on their input parsetrees. At this point I've lost count of how many > bugs that's caused (but e33f2335a and 0f43083d1 are the two latest > examples), and of how many places there are that are brute-forcing a > solution to the problem by copying a whole parsetree before letting > one of these subsystems see it. > > Years ago we fixed the executor to treat its input Plan trees as > read-only. It seems like we really ought to do the same for these > upstream subsystems. Surely, whatever benefit we get from changing > Node contents in-place is lost due to all these other hacks.
While I'm in favor of this idea, it seems that it will require lots of code changes. In particular, within the planner, the parsetree goes through considerable transformations during the preprocessing phase, such as subquery pull-up, constant folding, and so on. Would this proposal mean we'd need to refactor all those places to treat the input parsetrees as read-only? Just trying to understand the scope of what would be involved. Thanks Richard
