Re: unrecognized node type while displaying a Path due to dangling pointer
От | Ashutosh Bapat |
---|---|
Тема | Re: unrecognized node type while displaying a Path due to dangling pointer |
Дата | |
Msg-id | CAExHW5to+7bK_GjQmAnTqvV0r__ucwZ2y7=VYK=gxf=qiop3MA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: unrecognized node type while displaying a Path due to dangling pointer (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-hackers |
On Tue, Jul 18, 2023 at 5:05 AM David Rowley <dgrowleyml@gmail.com> wrote: > > On Mon, 17 Jul 2023 at 15:31, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > 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? > > CustomPaths, I didn't think about those. That certainly makes it more > complex. I also now see the header comment for struct CustomPath > mentioning that we don't copy Paths: Somewhere upthread Tom suggested using a dummy projection path. Add a projection path on top of input path and add the projection path to output rel's list. That will work right? There's some shallow copying code in reparameterize_path_by_childrel() but that's very specific to the purpose there and doesn't consider Custom or Foreign paths. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: