CustomPathMethods *methods;
} CustomPath;
</programlisting>
  </para>

  <para>
    <structfield>path</structfield> must be initialized as for any other path, including
    the row-count estimate, start and total cost, and sort ordering provided
    by this path.  <structfield>flags</structfield> is a bit mask, which
    specifies whether the scan provider can support certain optional
    capabilities.  <structfield>flags</structfield> should include
    <literal>CUSTOMPATH_SUPPORT_BACKWARD_SCAN</literal> if the custom path can support
    a backward scan, <literal>CUSTOMPATH_SUPPORT_MARK_RESTORE</literal> if it
    can support mark and restore,
    and <literal>CUSTOMPATH_SUPPORT_PROJECTION</literal> if it can perform
    projections.  (If <literal>CUSTOMPATH_SUPPORT_PROJECTION</literal> is not
    set, the scan node will only be asked to produce Vars of the scanned
    relation; while if that flag is set, the scan node must be able to
    evaluate scalar expressions over these Vars.)
    An optional <structfield>custom_paths</structfield> is a list of <structname>Path</structname>
    nodes used by this custom-path node; these will be transformed into
    <structname>Plan</structname> nodes by planner.
    As described below, custom paths can be created for join relations as
    well.  In such a case, <structfield>custom_restrictinfo</structfield>
    should be used to store the set of join clauses to apply to the join the
    custom path replaces.  Otherwise it should be NIL.
    <structfield>custom_private</structfield> can be used to store the custom path's
    private data.  Private data should be stored in a form that can be handled
    by <literal>nodeToString</literal>, so that debugging routines that attempt to
    print the custom path will work as designed.  <structfield>methods</structfield> must
    point to a (usually statically allocated) object implementing the required
    custom path methods, which are further detailed below.
  </para>

  <para>
   A custom scan provider can also provide join paths.  Just as for base
   relations, such a path must produce the same output as would normally be
   produced by the join it replaces.  To do this, the join provider should
   set the following hook, and then within the hook function,
   create <structname>CustomPath</structname> path(s) for the join relation.
<programlisting>
typedef void (*set_join_pathlist_hook_type) (PlannerInfo *root,
                                             RelOptInfo *joinrel,
                                             RelOptInfo *outerrel,
                                             RelOptInfo *innerrel,
                                             JoinType jointype,
                                             JoinPathExtraData *extra);
extern PGDLLIMPORT set_join_pathlist_hook_type set_join_pathlist_hook;
</programlisting>

   This hook will be invoked repeatedly for the same join relation, with
   different combinations of inner and outer relations; it is the
   responsibility of the hook to minimize duplicated work.
  </para>

  <para>
   Note also that the set of join clauses to apply to the join,
   which is passed as <literal>extra-&gt;restrictlist</literal>, varies
   depending on the combination of inner and outer relations.  A
   <structname>CustomPath</structname> path generated for the
   <literal>joinrel</literal> must contain the set of join clauses it uses,
   which will be used by the planner to convert the
   <structname>CustomPath</structname> path into a plan, if it is selected
   by the planner as the best path for the <literal>joinrel</literal>.
  </para>

  <sect2 id="custom-scan-path-callbacks">
  <title>Custom Scan Path Callbacks</title>

  <para>
<programlisting>
Plan *(*PlanCustomPath) (PlannerInfo *root,
                         RelOptInfo *rel,
                         CustomPath *best_path,
                         List *tlist,
                         List *clauses,
                         List *custom_plans);