Re: Violation of principle that plan trees are read-only
От | Yasir |
---|---|
Тема | Re: Violation of principle that plan trees are read-only |
Дата | |
Msg-id | CAA9OW9d7m-uXQWmc21-FuF--jd9306L_DrzYEyoOY-Ycun9gzg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Violation of principle that plan trees are read-only (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, May 19, 2025 at 7:45 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
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
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:
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.
- 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
Data Bene
В списке pgsql-hackers по дате отправления: