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 | CAApHDvo8tiB5xbJa94f4Mo8Of2fPJ2zG+zQQQTGr-ThjSsymQQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: unrecognized node type while displaying a Path due to dangling pointer (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: unrecognized node type while displaying a Path due to dangling pointer
|
Список | pgsql-hackers |
On Wed, 12 Jul 2023 at 14:50, David Rowley <dgrowleyml@gmail.com> wrote: > > 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've attached a draft patch which adds copyObjectFlat() and supports all Node types asides from the ones mentioned in @extra_tags in gen_node_support.pl. This did require including all the node header files in copyfuncs.c, which that file seems to have avoided until now. 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. I was also unsure what we should do when shallow copying a List. The problem there is if we just do a shallow copy, a repalloc() on the elements array would end up pfreeing memory that might be used by a shallow copied clone. Perhaps List is not unique in that regard? Maybe the solution there is to add a special case and list_copy() Lists like what is done in copyObjectImpl(). I'm hoping the attached patch will at least assist in moving the discussion along. David
Вложения
В списке pgsql-hackers по дате отправления: