Re: EvalPlanQual behaves oddly for FDW queries involving system columns - Mailing list pgsql-hackers

Ashutosh Bapat <ashutosh.bapat@enterprisedb.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