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