Re: unrecognized node type while displaying a Path due to dangling pointer
От | David Rowley |
---|---|
Тема | Re: unrecognized node type while displaying a Path due to dangling pointer |
Дата | |
Msg-id | CAApHDvqG5n+S4Ekbe6jPQZmyDehovLb_wh2jv2ixpZd7FX0HKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: unrecognized node type while displaying a Path due to dangling pointer (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: unrecognized node type while displaying a Path due to dangling pointer
|
Список | pgsql-hackers |
On Wed, 12 Jul 2023 at 14:23, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I did think about that, but "shallow copy a Path" seems nontrivial > because the Path structs are all different sizes. Maybe it is worth > building some infrastructure to support that? It seems a reasonable thing to have to do. It seems the minimum thing we could do to ensure each Path is only mentioned in at most 1 RelOptInfo. I see GetExistingLocalJoinPath() in foreign.c might be related to this problem, per: > * If the inner or outer subpath of the chosen path is a ForeignScan, we > * replace it with its outer subpath. For this reason, and also because the > * planner might free the original path later, the path returned by this > * function is a shallow copy of the original. There's no need to copy > * the substructure, so we don't. so that function could probably disappear if we had this. David
В списке pgsql-hackers по дате отправления: