From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: A modest proposal: make parser/rewriter/planner inputs read-only |
Date: | 2025-06-03 12:58:31 |
Message-ID: | CA+HiwqH044D+pCh66SAXCRuUyS4+wsqB8FPaxKaLUw3pBY8atg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 17, 2025 at 1:22 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-06-03 12:58:58 | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them |
Previous Message | Alena Rybakina | 2025-06-03 12:27:54 | Re: Vacuum statistics |