Add a GetForeignUpperPaths callback function for FDWs.

This is basically like the just-added create_upper_paths_hook, but
control is funneled only to the FDW responsible for all the baserels
of the current query; so providing such a callback is much less likely
to add useless overhead than using the hook function is.

The documentation is a bit sketchy.  We'll likely want to improve it,
and/or adjust the call conventions, when we get some experience with
actually using this callback.  Hopefully somebody will find time to
experiment with it before 9.6 feature freeze.

src/backend/optimizer/README

@@ -916,7 +916,10 @@ remote aggregation into the UPPERREL_GROUP_AGG upperrel, if it notices
 that the query represents an aggregation that could be done entirely on
 the foreign server.  That Path will then compete with Paths representing
 local aggregation on a regular scan of the foreign table, once the core
-planner reaches the point of considering aggregation.
+planner reaches the point of considering aggregation.  (In practice,
+it will usually be more convenient for FDWs to detect such cases in a
+GetForeignUpperPaths callback; but that still represents injecting a
+Path before the core code has touched the corresponding upperrel.)
 
 
 Parallel Query and Partial Paths

src/backend/optimizer/plan/planner.c

@@ -1752,13 +1752,17 @@ grouping_planner(PlannerInfo *root, bool inheritance_update,
 		root->upper_targets[UPPERREL_GROUP_AGG] = grouping_target;
 
 		/*
-		 * Let extensions, particularly CustomScan providers, consider
-		 * injecting extension Paths into the query's upperrels, where they
-		 * will compete with the Paths we create below.  We pass the final
-		 * scan/join rel because that's not so easily findable from the
-		 * PlannerInfo struct; anything else the hook wants to know should be
-		 * obtainable via "root".
+		 * Let extensions, particularly FDWs and CustomScan providers,
+		 * consider injecting extension Paths into the query's upperrels,
+		 * where they will compete with the Paths we create below.  We pass
+		 * the final scan/join rel because that's not so easily findable from
+		 * the PlannerInfo struct; anything else the hooks want to know should
+		 * be obtainable via "root".
 		 */
+		if (current_rel->fdwroutine &&
+			current_rel->fdwroutine->GetForeignUpperPaths)
+			current_rel->fdwroutine->GetForeignUpperPaths(root, current_rel);
+
 		if (create_upper_paths_hook)
 			(*create_upper_paths_hook) (root, current_rel);
 

src/backend/optimizer/util/pathnode.c

@@ -1813,15 +1813,15 @@ create_worktablescan_path(PlannerInfo *root, RelOptInfo *rel,
 
 /*
  * create_foreignscan_path
- *	  Creates a path corresponding to a scan of a foreign table or
- *	  a foreign join, returning the pathnode.
+ *	  Creates a path corresponding to a scan of a foreign table, foreign join,
+ *	  or foreign upper-relation processing, returning the pathnode.
  *
  * This function is never called from core Postgres; rather, it's expected
- * to be called by the GetForeignPaths or GetForeignJoinPaths function of
- * a foreign data wrapper.  We make the FDW supply all fields of the path,
- * since we do not have any way to calculate them in core.  However, there
- * is a sane default for the pathtarget (rel->reltarget), so we let a NULL
- * for "target" select that.
+ * to be called by the GetForeignPaths, GetForeignJoinPaths, or
+ * GetForeignUpperPaths function of a foreign data wrapper.  We make the FDW
+ * supply all fields of the path, since we do not have any way to calculate
+ * them in core.  However, there is a usually-sane default for the pathtarget
+ * (rel->reltarget), so we let a NULL for "target" select that.
  */
 ForeignPath *
 create_foreignscan_path(PlannerInfo *root, RelOptInfo *rel,