Re: A modest proposal: make parser/rewriter/planner inputs read-only

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

In response to

Browse pgsql-hackers by date

  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