relevant to
     the particular foreign table.  The core planner does not touch it except
     to initialize it to NULL when the <literal>RelOptInfo</literal> node is created.
     It is useful for passing information forward from
     <function>GetForeignRelSize</function> to <function>GetForeignPaths</function> and/or
     <function>GetForeignPaths</function> to <function>GetForeignPlan</function>, thereby
     avoiding recalculation.
    </para>

    <para>
     <function>GetForeignPaths</function> can identify the meaning of different
     access paths by storing private information in the
     <structfield>fdw_private</structfield> field of <structname>ForeignPath</structname> nodes.
     <structfield>fdw_private</structfield> is declared as a <type>List</type> pointer, but
     could actually contain anything since the core planner does not touch
     it.  However, best practice is to use a representation that's dumpable
     by <function>nodeToString</function>, for use with debugging support available
     in the backend.
    </para>

    <para>
     <function>GetForeignPlan</function> can examine the <structfield>fdw_private</structfield>
     field of the selected <structname>ForeignPath</structname> node, and can generate
     <structfield>fdw_exprs</structfield> and <structfield>fdw_private</structfield> lists to be
     placed in the <structname>ForeignScan</structname> plan node, where they will be
     available at execution time.  Both of these lists must be
     represented in a form that <function>copyObject</function> knows how to copy.
     The <structfield>fdw_private</structfield> list has no other restrictions and is
     not interpreted by the core backend in any way.  The
     <structfield>fdw_exprs</structfield> list, if not NIL, is expected to contain
     expression trees that are intended to be executed at run time.  These
     trees will undergo post-processing by the planner to make them fully
     executable.
    </para>

    <para>
     In <function>GetForeignPlan</function>, generally the passed-in target list can
     be copied into the plan node as-is.  The passed <literal>scan_clauses</literal> list
     contains the same clauses as <literal>baserel-&gt;baserestrictinfo</literal>,
     but may be re-ordered for better execution efficiency.  In simple cases
     the FDW can just strip <structname>RestrictInfo</structname> nodes from the
     <literal>scan_clauses</literal> list (using <function>extract_actual_clauses</function>) and put
     all the clauses into the plan node's qual list, which means that all the
     clauses will be checked by the executor at run time.  More complex FDWs
     may be able to check some of the clauses internally, in which case those
     clauses can be removed from the plan node's qual list so that the
     executor doesn't waste time rechecking them.
    </para>

    <para>
     As an example, the FDW might identify some restriction clauses of the
     form <replaceable>foreign_variable</replaceable> <literal>=</literal>
     <replaceable>sub_expression</replaceable>, which it determines can be executed on
     the remote server given the locally-evaluated value of the
     <replaceable>sub_expression</replaceable>.  The actual identification of such a
     clause should happen during <function>GetForeignPaths</function>, since it would
     affect the cost estimate for the path.  The path's
     <structfield>fdw_private</structfield> field would probably include a pointer to
     the identified clause's <structname>RestrictInfo</structname> node.  Then
     <function>GetForeignPlan</function> would remove that clause from <literal>scan_clauses</literal>,
     but add the <replaceable>sub_expression</replaceable> to <structfield>fdw_exprs</structfield>
     to ensure that it gets massaged into executable form.  It would probably
     also put control information into the plan node's
     <structfield>fdw_private</structfield> field to tell the execution functions