Re: Violation of principle that plan trees are read-only

On Mon, 19 May 2025 at 08:35, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, May 18, 2025 at 7:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > While chasing down Valgrind leakage reports, I was disturbed
> > to realize that some of them arise from a case where the
> > executor scribbles on the plan tree it's given, which it is
> > absolutely not supposed to do:
> >
> > /*
> > * Initialize result tuple slot and assign its rowtype using the
> first
> > * RETURNING list. We assume the rest will look the same.
> > */
> > mtstate->ps.plan->targetlist = (List *) linitial(returningLists);
> >
> > A bit of git archaeology fingers Andres' commit 4717fdb14, which we
> > can't easily revert since he later got rid of ExecAssignResultType
> > altogether. But I think we need to do something about it --- it's
> > purest luck that this doesn't cause serious problems in some cases.
>
> Is there some way that we can detect violations of this rule
> automatically? I recall that we were recently discussing with Richard
> Guo a proposed patch that would have had a similar problem, so it's
> evidently not that hard for a committer to either fail to understand
> what the rule is or fail to realize that they are violating it.

I assume this question has an obvious negative answer, but why can't we
attach const declarations to the various structures that make up the plan
tree (at all levels, all the way down)? I know const doesn't actually
prevent a value from changing, but at least the compiler would complain if
code accidentally tried.