Run-time pruning for ModifyTable

Deja vu from this time last year when despite everyone's best efforts
(mostly Alvaro) we missed getting run-time pruning in for MergeAppend
into the PG11 release. This year it was ModifyTable, which is now
possible thanks to Amit and Tom's modifications to the inheritance
planner.

I've attached what I have so far for this. I think it's mostly okay,
but my brain was overheating a bit at the inheritance_planner changes.
I'm not entirely certain that what I've got is correct there. My brain
struggled a bit with the code that Tom wrote to share the data
structures from the SELECT invocation of the grouping_planner() in
inheritance_planner() regarding subquery RTEs. I had to pull out some
more structures from the other PlannerInfo structure in order to get
the base quals from the target rel. I don't quite see a reason why
it's particularly wrong to tag those onto the final_rel, but I'll
prepare myself to be told that I'm wrong about that.

I'm not particularly happy about having to have written the
IS_DUMMY_MODIFYTABLE macro. I just didn't see a more simple way to
determine if the ModifyTable just contains a single dummy Append path.

I also had to change the ModifyTable resultRelInfo pointer to an array
of pointers. This seems to be required since we need to somehow ignore
ResultRelInfos which were pruned. I didn't do any performance testing
for the added level of indirection, I just imagined that it's
unmeasurable.

I'll include this in for July 'fest.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services