<programlisting>
void
BeginForeignScan(ForeignScanState *node,
int eflags);
</programlisting>
Begin executing a foreign scan. This is called during executor startup.
It should perform any initialization needed before the scan can start,
but not start executing the actual scan (that should be done upon the
first call to <function>IterateForeignScan</function>).
The <structname>ForeignScanState</structname> node has already been created, but
its <structfield>fdw_state</structfield> field is still NULL. Information about
the table to scan is accessible through the
<structname>ForeignScanState</structname> node (in particular, from the underlying
<structname>ForeignScan</structname> plan node, which contains any FDW-private
information provided by <function>GetForeignPlan</function>).
<literal>eflags</literal> contains flag bits describing the executor's
operating mode for this plan node.
</para>
<para>
Note that when <literal>(eflags & EXEC_FLAG_EXPLAIN_ONLY)</literal> is
true, this function should not perform any externally-visible actions;
it should only do the minimum required to make the node state valid
for <function>ExplainForeignScan</function> and <function>EndForeignScan</function>.
</para>
<para>
<programlisting>
TupleTableSlot *
IterateForeignScan(ForeignScanState *node);
</programlisting>
Fetch one row from the foreign source, returning it in a tuple table slot
(the node's <structfield>ScanTupleSlot</structfield> should be used for this
purpose). Return NULL if no more rows are available. The tuple table
slot infrastructure allows either a physical or virtual tuple to be
returned; in most cases the latter choice is preferable from a
performance standpoint. Note that this is called in a short-lived memory
context that will be reset between invocations. Create a memory context
in <function>BeginForeignScan</function> if you need longer-lived storage, or use
the <structfield>es_query_cxt</structfield> of the node's <structname>EState</structname>.
</para>
<para>
The rows returned must match the <structfield>fdw_scan_tlist</structfield> target
list if one was supplied, otherwise they must match the row type of the
foreign table being scanned. If you choose to optimize away fetching
columns that are not needed, you should insert nulls in those column
positions, or else generate a <structfield>fdw_scan_tlist</structfield> list with
those columns omitted.
</para>
<para>
Note that <productname>PostgreSQL</productname>'s executor doesn't care
whether the rows returned violate any constraints that were defined on
the foreign table — but the planner does care, and may optimize
queries incorrectly if there are rows visible in the foreign table that
do not satisfy a declared constraint. If a constraint 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