Re: unrecognized node type while displaying a Path due to dangling pointer
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Jeevan Chalke <jeevan.chalke@enterprisedb.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-19T08:39:30Z
Lists: 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