<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 what
     to do at run time.  The query transmitted to the remote server would
     involve something like <literal>WHERE <replaceable>foreign_variable</replaceable> =
     $1</literal>, with the parameter value obtained at run time from
     evaluation of the <structfield>fdw_exprs</structfield> expression tree.
    </para>

    <para>
     Any clauses removed from the plan node's qual list must instead be added
     to <literal>fdw_recheck_quals</literal> or rechecked by
     <literal>RecheckForeignScan</literal> in order to ensure correct behavior
     at the <literal>READ COMMITTED</literal> isolation level.  When a concurrent
     update occurs for some other table involved in the query, the executor
     may need to verify that all of the original quals are still satisfied for
     the tuple, possibly against a different set of parameter values.  Using
     <literal>fdw_recheck_quals</literal> is typically easier than implementing checks
     inside <literal>RecheckForeignScan</literal>, but this method will be
     insufficient when outer joins have been pushed down, since the join tuples
     in that case might have some fields go to NULL without rejecting the
     tuple entirely.
    </para>

    <para>
     Another <structname>ForeignScan</structname> field that can be filled by FDWs
     is <structfield>fdw_scan_tlist</structfield>, which describes the tuples returned by
     the FDW for this plan node.  For simple foreign table scans this can be
     set to <literal>NIL</literal>, implying that the returned tuples have the
     row type declared for the foreign table.  A non-<symbol>NIL</symbol> value must be a
     target list (list of <structname>TargetEntry</structname>s) containing Vars and/or
     expressions representing the returned columns.  This might be used, for
     example, to show that the FDW has omitted some columns that it noticed
     won't be needed for the query.  Also, if the FDW can compute expressions
     used by the query more cheaply than can be done locally, it could add
     those expressions to <structfield>fdw_scan_tlist</structfield>.  Note that join
     plans (created from paths made by <function>GetForeignJoinPaths</function>) must
     always supply <structfield>fdw_scan_tlist</structfield> to describe the set of
     columns they will return.
    </para>

    <para>
     The FDW should always construct at least one path that depends only on
     the table's restriction clauses.  In join queries, it might also choose
     to construct path(s) that depend on join clauses, for example
     <replaceable>foreign_variable</replaceable> <literal>=</literal>
     <replaceable>local_variable</replaceable>.  Such clauses will not be found in
     <literal>baserel-&gt;baserestrictinfo</literal> but must be sought in the
     relation's join lists.  A path using such a clause is called a
     <quote>parameterized path</quote>.  It must identify the other relations
     used in the selected