Re: EvalPlanQual behaves oddly for FDW queries involving system columns

Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> I will leave this issue for the committer to judge. Changed the status to
> "ready for committer".

I don't like the execMain.c changes much at all. They look somewhat
like they're intended to allow foreign tables to adopt a different
locking strategy, but if so they belong in a different patch that
actually implements such a thing. The changes are not all consistent
either, eg this:

! if (erm->relation &&
! erm->relation->rd_rel->relkind != RELKIND_FOREIGN_TABLE)

is not necessary if this Assert is accurate:

! if (erm->relation)
! {
! Assert(erm->relation->rd_rel->relkind == RELKIND_FOREIGN_TABLE);

I don't see the need for the change in nodeForeignscan.c. If the FDW has
returned a physical tuple, it can fix that for itself, while if it has
returned a virtual tuple, the ctid will be garbage in any case.

regards, tom lane