Home Explore Blog CI



postgresql

4th chunk of `doc/src/sgml/fdwhandler.sgml`
737fa8402b8d627a69597258defd4ade0a5620516d7e1dd90000000100000fa2

<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 &amp; 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 &mdash; 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

Title: FDW Routines for Foreign Scan Execution: BeginForeignScan, IterateForeignScan, ReScanForeignScan, and EndForeignScan
Summary
This section details the FDW routines involved in executing a foreign scan: `BeginForeignScan`, `IterateForeignScan`, `ReScanForeignScan`, and `EndForeignScan`. `BeginForeignScan` initializes the scan, `IterateForeignScan` fetches rows, `ReScanForeignScan` restarts the scan, and `EndForeignScan` releases resources. It also discusses considerations for handling constraints and optimizing column fetching.