Kyotaro HORIGUCHI <kyota.horiguchi@gmail.com> writes:
> If my understanding about non-system junk columns in a base relation
> and identifiers of a foreign tuples are correct, what is needed here
> is giving base relations the ability to have such junk column.
The core of the problem, I think, is the question of exactly what
postgresAddForeignUpdateTargets should put into the resjunk expressions
it adds to an update/delete query's targetlist. Per discussion yesterday,
up to now it's always emitted Vars referencing the foreign relation,
which is problematic because with that approach the desired info has
to be exposed as either a regular or system column of that relation.
But there's nothing saying that the expression has to be a Var.
My thought about what we might do instead is that
postgresAddForeignUpdateTargets could reserve a PARAM_EXEC slot
and emit a Param node referencing that. Then at runtime, while
reading a potential target row from the remote, we fill that
param slot along with the regular scan tuple slot.
What you want for the first part of that is basically like
generate_new_param() in subselect.c. We don't expose that publicly
at the moment, but we could, or maybe better to invent another wrapper
around it like SS_make_initplan_output_param.
regards, tom lane
