Re: unrecognized node type while displaying a Path due to dangling pointer

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 12 Jul 2023 at 14:50, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>> On Wed, 12 Jul 2023 at 14:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 also didn't do anything about ExtensibleNode types. I assume just
> copying the ExtensibleNode isn't good enough. To flat copy the actual
> node I think would require adding a new function to
> ExtensibleNodeMethods.

Yeah, the problem I've got with this approach is that flat-copying
FDW and Custom paths would require extending the respective APIs.
While that's a perfectly reasonable ask if we only need to do this
in HEAD, it would be a nonstarter for released branches. Is it
okay to only fix this issue in HEAD?

> I was also unsure what we should do when shallow copying a List.

The proposal is to shallow-copy a Path node. List is not a kind
of Path, so how does List get into it? (Lists below Paths would
not get copied, by definition.)

regards, tom lane