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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: A modest proposal: make parser/rewriter/planner inputs read-only
Date: 2025-04-15 09:20:42
Message-ID: CAMbWs4_9ozYZi4_s8DqVKDtOmYTmeRgQ0pZcZh1b4+3VxD8XXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 6, 2025 at 1:46 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ilia Evdokimov 2025-04-15 09:44:13 Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Previous Message Daniel Gustafsson 2025-04-15 09:02:19 Re: minor error message enhancement in refuseDupeIndexAttach