On Thu, Apr 17, 2025 at 1:22 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Now, subquery_planner does have side effects on the PlannerGlobal > struct, but that's planner-local data, not an input to the planner.
That reminded me of one place where we currently mutate planner input: inserting child RTEs into each subquery’s Query->rtable -- for inheritance, partitioning, UNION ALL, etc. That seems like a pretty clear violation of the read-only boundary. If we instead accumulated those RTEs (especially child RTEs) in a global list -- maybe in PlannerGlobal -- we could install that directly into PlannedStmt->rtable at the end. That would avoid the need for set_plan_refs() to reconstruct the rtable from scattered per-query trees and also sidestep the rtoffset plumbing when stitching plan trees together. I recall there’s been some desire for something like that in the past (maybe not from you specifically), and it seems in line with the overall direction here -- making it clearer which data is planner-local and mutable, and which is considered stable input or final output. Right now that boundary gets blurred when the planner modifies Query->rtable directly and later has to patch things back up; a dedicated global structure could make that separation more explicit and intentional. One thing that would change is how we handle pruned subqueries. Right now, set_plan_refs() drops RTEs that are only referenced by subqueries eliminated during planning. If we shift to preserving a planner-global list of all added RTEs, we might keep more than necessary unless we reintroduce a pruning step. That might be acceptable, but it's something we'd want to think through. We could perhaps spin this and other related preparatory projects into a separate thread, but thought to bring this up while it's fresh. -- Thanks, Amit Langote
