<function>GetForeignJoinPaths</function>,
     it is not necessary that this function succeed in creating any paths,
     since paths involving local processing are always possible.
    </para>

    <para>
     The <literal>stage</literal> parameter identifies which post-scan/join step is
     currently being considered.  <literal>output_rel</literal> is the upper relation
     that should receive paths representing computation of this step,
     and <literal>input_rel</literal> is the relation representing the input to this
     step.  The <literal>extra</literal> parameter provides additional details,
     currently, it is set only for <literal>UPPERREL_PARTIAL_GROUP_AGG</literal>
     or <literal>UPPERREL_GROUP_AGG</literal>, in which case it points to a
     <literal>GroupPathExtraData</literal> structure;
     or for <literal>UPPERREL_FINAL</literal>, in which case it points to a
     <literal>FinalPathExtraData</literal> structure.
     (Note that <structname>ForeignPath</structname> paths added
     to <literal>output_rel</literal> would typically not have any direct dependency
     on paths of the <literal>input_rel</literal>, since their processing is expected
     to be done externally.  However, examining paths previously generated for
     the previous processing step can be useful to avoid redundant planning
     work.)
    </para>

    <para>
     See <xref linkend="fdw-planning"/> for additional information.
    </para>
   </sect2>

   <sect2 id="fdw-callbacks-update">
    <title>FDW Routines for Updating Foreign Tables</title>

    <para>
     If an FDW supports writable foreign tables, it should provide
     some or all of the following callback functions depending on
     the needs and capabilities of the FDW:
    </para>

    <para>
<programlisting>
void
AddForeignUpdateTargets(PlannerInfo *root,
                        Index rtindex,
                        RangeTblEntry *target_rte,
                        Relation target_relation);
</programlisting>

     <command>UPDATE</command> and <command>DELETE</command> operations are performed
     against rows previously fetched by the table-scanning functions.  The
     FDW may need extra information, such as a row ID or the values of
     primary-key columns, to ensure that it can identify the exact row to
     update or delete.  To support that, this function can add extra hidden,
     or <quote>junk</quote>, target columns to the list of columns that are to be
     retrieved from the foreign table during an <command>UPDATE</command> or
     <command>DELETE</command>.
    </para>

    <para>
     To do that, construct a <structname>Var</structname> representing
     an extra value you need, and pass it
     to <function>add_row_identity_var</function>, along with a name for
     the junk column.  (You can do this more than once if several columns
     are needed.)  You must choose a distinct junk column name for each
     different <structname>Var</structname> you need, except
     that <structname>Var</structname>s that are identical except for
     the <structfield>varno</structfield> field can and should share a
     column name.
     The core system uses the junk column names
     <literal>tableoid</literal> for a
     table's <structfield>tableoid</structfield> column,
     <literal>ctid</literal>
     or <literal>ctid<replaceable>N</replaceable></literal>
     for <structfield>ctid</structfield>,
     <literal>wholerow</literal>
     for a whole-row <structname>Var</structname> marked with
     <structfield>vartype</structfield> = <type>RECORD</type>,
     and <literal>wholerow<replaceable>N</replaceable></literal>
     for a whole-row <structname>Var</structname> with
     <structfield>vartype</structfield> equal to the table's declared row type.
     Re-use these names when you can (the planner will combine duplicate
     requests for identical junk columns).  If you need another kind of
     junk column besides these, it might be wise to choose a name