From: | Yasir <yasir(dot)hussain(dot)shah(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Violation of principle that plan trees are read-only |
Date: | 2025-05-21 05:01:56 |
Message-ID: | CAA9OW9d7m-uXQWmc21-FuF--jd9306L_DrzYEyoOY-Ycun9gzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 19, 2025 at 7:45 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
> > 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.
>
> The big problem is that a "const" attached to a top-level pointer
> doesn't inherently propagate down to sub-nodes. So if I had, say,
> "const Query *stmt", the compiler would complain about
>
> stmt->jointree = foo;
>
> but not about
>
> stmt->jointree->quals = foo;
>
> I guess we could imagine developing an entirely parallel set of
> struct declarations with "const" on all pointer fields, like
>
> typedef struct ConstQuery
> {
> ...
> const ConstFromExpr *jointree;
> ...
> } ConstQuery;
>
> but even with automated maintenance of the ConstFoo doppelganger
> typedefs, it seems like that'd be a notational nightmare. For
> one thing, I'm not sure how to teach the compiler that casting
> "Query *" to "ConstQuery *" is okay but vice versa isn't.
>
> Does C++ have a better story in this area? I haven't touched it
> in so long that I don't remember.
>
> regards, tom lane
>
>
One unconventional but potentially effective approach to detect unexpected
modifications in the plan tree can be as follows:
- Implement a function that can deeply compare two plan trees for
structural or semantic differences.
- Before passing the original plan tree to the executor, make a deep
copy of it.
- After execution (or at strategic checkpoints), compare the current
plan tree against the original copy.
- If any differences are detected, emit a warning or log it for further
inspection.
Yes, this approach introduces some memory and performance overhead.
However, we can limit its impact by enabling it conditionally via a
compile-time flag or #define, making it suitable for debugging or
assertion-enabled builds.
It might sound a bit unconventional, but it could serve as a useful sanity
check especially during development or when investigating plan tree
integrity issues.
Pardon me if this sounds naive!
Yasir
Data Bene
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2025-05-21 05:15:27 | Re: proposal: schema variables |
Previous Message | Amit Kapila | 2025-05-21 04:54:41 | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |