@@ -2020,12 +2020,11 @@ postgresBeginForeignInsert(ModifyTableState *mtstate,
20202020 /*
20212021 * If the foreign table is a partition, we need to create a new RTE
20222022 * describing the foreign table for use by deparseInsertSql and
2023- * create_foreign_modify() below, after first copying the parent's
2024- * RTE and modifying some fields to describe the foreign partition to
2025- * work on. However, if this is invoked by UPDATE, the existing RTE
2026- * may already correspond to this partition if it is one of the
2027- * UPDATE subplan target rels; in that case, we can just use the
2028- * existing RTE as-is.
2023+ * create_foreign_modify() below, after first copying the parent's RTE and
2024+ * modifying some fields to describe the foreign partition to work on.
2025+ * However, if this is invoked by UPDATE, the existing RTE may already
2026+ * correspond to this partition if it is one of the UPDATE subplan target
2027+ * rels; in that case, we can just use the existing RTE as-is.
20292028 */
20302029 rte = list_nth (estate -> es_range_table , resultRelation - 1 );
20312030 if (rte -> relid != RelationGetRelid (rel ))
@@ -2035,10 +2034,10 @@ postgresBeginForeignInsert(ModifyTableState *mtstate,
20352034 rte -> relkind = RELKIND_FOREIGN_TABLE ;
20362035
20372036 /*
2038- * For UPDATE, we must use the RT index of the first subplan
2039- * target rel's RTE, because the core code would have built
2040- * expressions for the partition, such as RETURNING, using that
2041- * RT index as varno of Vars contained in those expressions.
2037+ * For UPDATE, we must use the RT index of the first subplan target
2038+ * rel's RTE, because the core code would have built expressions for
2039+ * the partition, such as RETURNING, using that RT index as varno of
2040+ * Vars contained in those expressions.
20422041 */
20432042 if (plan && plan -> operation == CMD_UPDATE &&
20442043 resultRelation == plan -> nominalRelation )
0 commit comments