On Thu, Jul 24, 2025 at 12:48 PM Tomas Vondra <to...@vondra.me> wrote: > I was thinking about this a bit more, and I think the CustomScan join > essentially has to construct it's own info how to build the tuple, most > likely in PlanCustomPath, because once setrefs.c does it's thing it's > way too late for that I think. And the only way to store that is > custom_private, so no fancy custom structs. I'll give it a try.
Yeah, I think that's probably right. > Seems much more convenient to allow doing what regulars joins do, and > only force the extension to do the manual stuff if it wants to do > something like multiway-joins ... I think that the motivating use case for the existing support was wanting to offload work to something that looks altogether unlike the normal PostgreSQL executor, rather than (as you want to do) implement a new type of join within the PostgreSQL executor. The latter might merit different infrastructure, although I cringe a little bit at the idea of having two ways of implementing custom joins when the total number of projects using this infrastructure is probably less than five. -- Robert Haas EDB: http://www.enterprisedb.com
