Re: Using FDW AddForeignUpdateTargets for a hidden pseudo-column

A very quick and dirty hack I did in src/backend/optimizer/plan/initsplan.c (in 9.5.3):

--- initsplan.c.orig 2016-06-14 19:08:27.000000000 +0600
+++ initsplan.c 2016-06-14 19:10:55.000000000 +0600
@@ -185,9 +185,12 @@
if (IsA(node, Var))
{
Var *var = (Var *) node;
- RelOptInfo *rel = find_base_rel(root, var->varno);
+ RelOptInfo *rel;
int attno = var->varattno;

+ if (var->varno == INDEX_VAR)
+ continue;
+ rel = find_base_rel(root, var->varno);
if (bms_is_subset(where_needed, rel->relids))
continue;
Assert(attno >= rel->min_attr && attno <= rel->max_attr);

And then in my FDW I add the tuple id column like this:

static void
MyAddForeignUpdateTargets(Query *parsetree,
RangeTblEntry *target_rte,
Relation target_relation)
{
Var *var;
TargetEntry *tle;

/* Make a Var representing the desired value */
var = makeVar(INDEX_VAR, /* instead of parsetree->resultRelation,*/
target_relation->rd_att->natts + 1,
INT8OID,
-1,
InvalidOid,
0);

/* Wrap it in a resjunk TLE with the right name ... */
tle = makeTargetEntry((Expr *) var,
list_length(parsetree->targetList) + 1,
pstrdup(MY_FDW_TUPLE_ID),
true);

/* ... and add it to the query's targetlist */
parsetree->targetList = lappend(parsetree->targetList, tle);
}

I was able to run successfully a couple of very simple tests with these. This seems to
indicate that tweaking the core to handle this case properly is doable.

The question is if this approach is conceptually correct and if so what are the other
required places to patch.

Regards,
Aleksey