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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
