> Andres Freund <andres@2ndquadrant.com> writes:
> > What I think this discussion shows that this patch isn't ready for
> > 9.4. The first iteration of the patch came in 2013-11-06. Imo that's
> > pretty damn late for a relatively complex patch. And obviously we
> > don't have agreement on the course forward.
> > I don't think we need to stop discussing, but I think it's pretty
> > clear that this isn't 9.4 material. And that it's far from "Ready for
> Committer".
>
Yep, today is the expected feature freeze date towards v9.4.
It is little bit late to include v9.4 features, unfortunately.
> Yeah. I'm still not exactly convinced that custom-scan will ever allow
> independent development of new plan types (which, with all due respect to
> Robert, is what it was being sold as last year in Ottawa). But I'm not
> opposed in principle to committing it, if we can find a way to have a cleaner
> API for things like setrefs.c. It seems like late-stage planner processing
> in general is an issue for this patch (createplan.c and subselect.c are
> also looking messy). EXPLAIN isn't too great either.
>
> I'm not sure exactly what to do about those cases, but I wonder whether
> things would get better if we had the equivalent of
> expression_tree_walker/mutator capability for plan nodes. The state of
> affairs in setrefs and subselect, at least, is a bit reminiscent of the
> bad old days when we had lots of different bespoke code for traversing
> expression trees.
>
Hmm. If we have something like expression_tree_walker/mutator for plan nodes,
we can pass a walker/mutator function's pointer instead of exposing static
functions that takes recursive jobs.
If custom-plan provider (that has sub-plans) got a callback with walker/
mutator pointer, all it has to do for sub-plans are calling this new
plan-tree walking support routine with supplied walker/mutator.
It seems to me more simple design than what I did.
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
