>> 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. > I tried to code the similar walker/mutator functions on plan-node tree, however, it was not available to implement these routines enough simple, because the job of walker/mutator functions are not uniform thus caller side also must have a large switch-case branches.
I picked up setrefs.c for my investigation. The set_plan_refs() applies fix_scan_list() on the expression tree being appeared in the plan node if it is delivered from Scan, however, it also applies set_join_references() for subclass of Join, or set_dummy_tlist_references() for some other plan nodes. It implies that the walker/mutator functions of Plan node has to apply different operation according to the type of Plan node. I'm not certain how much different forms are needed. (In addition, set_plan_refs() performs usually like a walker, but often performs as a mutator if trivial subquery....) I'm expecting the function like below. It allows to call plan_walker function for each plan-node and also allows to call expr_walker function for each expression-node on the plan node. bool plan_tree_walker(Plan *plan, bool (*plan_walker) (), bool (*expr_walker) (), void *context) I'd like to see if something other form to implement this routine. One alternative idea to give custom-plan provider a chance to handle its subplans is, to give function pointers (1) to handle recursion of plan-tree and (2) to set up backend's internal state. In case of setrefs.c, set_plan_refs() and fix_expr_common() are minimum necessity for extensions. It also kills necessity to export static functions. How about your thought? -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers