Isaac Morland <isaac.morland@gmail.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
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.
