is violated when
     the user has declared that the constraint should hold true, it may be
     appropriate to raise an error (just as you would need to do in the case
     of a data type mismatch).
    </para>

    <para>
<programlisting>
void
ReScanForeignScan(ForeignScanState *node);
</programlisting>

     Restart the scan from the beginning.  Note that any parameters the
     scan depends on may have changed value, so the new scan does not
     necessarily return exactly the same rows.
    </para>

    <para>
<programlisting>
void
EndForeignScan(ForeignScanState *node);
</programlisting>

     End the scan and release resources.  It is normally not important
     to release palloc'd memory, but for example open files and connections
     to remote servers should be cleaned up.
    </para>

   </sect2>

   <sect2 id="fdw-callbacks-join-scan">
    <title>FDW Routines for Scanning Foreign Joins</title>

    <para>
     If an FDW supports performing foreign joins remotely (rather than
     by fetching both tables' data and doing the join locally), it should
     provide this callback function:
    </para>

    <para>
<programlisting>
void
GetForeignJoinPaths(PlannerInfo *root,
                    RelOptInfo *joinrel,
                    RelOptInfo *outerrel,
                    RelOptInfo *innerrel,
                    JoinType jointype,
                    JoinPathExtraData *extra);
</programlisting>
     Create possible access paths for a join of two (or more) foreign tables
     that all belong to the same foreign server.  This optional
     function is called during query planning.  As
     with <function>GetForeignPaths</function>, this function should
     generate <structname>ForeignPath</structname> path(s) for the
     supplied <literal>joinrel</literal>
     (use <function>create_foreign_join_path</function> to build them),
     and call <function>add_path</function> to add these
     paths to the set of paths considered for the join.  But unlike
     <function>GetForeignPaths</function>, it is not necessary that this function
     succeed in creating at least one path, since paths involving local
     joining are always possible.
    </para>

    <para>
     Note that this function will be invoked repeatedly for the same join
     relation, with different combinations of inner and outer relations; it is
     the responsibility of the FDW 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>ForeignPath</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>ForeignPath</structname> path into a plan, if it is selected
     by the planner as the best path for the <literal>joinrel</literal>.
    </para>

    <para>
     If a <structname>ForeignPath</structname> path is chosen for the join, it will
     represent the entire join process; paths generated for the component
     tables and subsidiary joins will not be used.  Subsequent processing of
     the join path proceeds much as it does for a path scanning a single
     foreign table.  One difference is that the <structfield>scanrelid</structfield> of
     the resulting <structname>ForeignScan</structname> plan node should be set to zero,
     since there is no single relation that it represents; instead,
     the <structfield>fs_relids</structfield> field of the <structname>ForeignScan</structname>
     node represents the set of relations that were joined.  (The latter field
     is set up automatically by the core planner code, and need not be filled
     by the FDW.)  Another difference is that, because the column list for a
     remote join cannot be found from the system catalogs, the FDW must
     fill <structfield>fdw_scan_tlist</structfield>