> A possible compromise that we could perhaps still wedge into 9.5 is to
> extend CustomPath with a List of child Paths, and CustomScan with a List
> of child Plans, which createplan.c would know to build from the Paths,
> and other modules would then also be aware of these children. I find that
> uglier than a separate join node type, but it would be tolerable I guess.
>
The attached patch implements what you suggested as is.
It allows custom-scan providers to have child Paths without exporting
create_plan_recurse(), and enables to represent N-way join naturally.
Please add any solution, even if we don't reach the consensus of how
create_plan_recurse (and other useful static functions) are visible to
extensions.
Patch detail:
It adds a List field (List *custom_children) to CustomPath structure
to inform planner its child Path nodes, to be transformed to Plan node
through the planner's job.
CustomScan also have a new List field to have its child Plan nodes
which shall be processed by setrefs.c and subselect.c.
PlanCustomPath callback was extended to have a list of Plan nodes
that were constructed on create_customscan_plan in core, it is
a job of custom-scan provider to attach these Plan nodes onto
lefttree, righttree or the custom_children list.
CustomScanState also have an array to have PlanState nodes of the
children. It is used for EXPLAIN command know the child nodes.
Regarding of FDW, as Hanada-san mentioned, I'm uncertain whether
similar feature is also needed because its join-pushdown feature
scan on the result-set of remotely joined relations, thus no need
to have local child Path nodes.
So, I put this custom_children list on CustomXXXX structure only.
It may need additional section in the documentation.
Thanks,
--
NEC Business Creation Division / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>