On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I wrote:
>> Apparently, postgres_fdw is trying to store RestrictInfos in the
>> fdw_private field of a ForeignScan node.  That won't do; those aren't
>> supposed to be present in a finished plan tree, so there's no readfuncs.c
>> support for them (and we're not adding it).
>> Don't know if this is a new bug, or ancient but not previously reachable.
>> It seems to be nearly the inverse of the problem you found yesterday,
>> in which postgres_fdw was stripping RestrictInfos sooner than it really
>> ought to.  Apparently that whole business needs a fresh look.
> Attached is a proposed patch that cleans up the mess here --- and it was
> a mess.  The comments for PgFdwRelationInfo claimed that the remote_conds
> and local_conds fields contained bare clauses, but actually they could
> contain either bare clauses or RestrictInfos or both, depending on where
> the clauses had come from.  And there was some seriously obscure and
> undocumented logic around how the fdw_recheck_quals got set up for a
> foreign join node.  (BTW, said logic is assuming that no EPQ recheck is
> needed for a foreign join.  I commented it to that effect, but I'm not
> very sure that I believe it.  If there's a bug there, though, it's
> independent of the immediate problem.)
> Anybody want to review this, or shall I just push it?

Will be reviewing it in a couple of hours.
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to