From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
cc: Andreas Seltenreich <seltenreich@gmx.de>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...
In-reply-to: 
 <CAFjFpRdvS56ne6uoy9y3ZRWkFUWEEpCt=w8hwt9wrHWWPYDPeQ@mail.gmail.com>
References: <87tw5x4vcu.fsf@credativ.de> <11668.1491753112@sss.pgh.pa.us>
 <9631.1491863013@sss.pgh.pa.us>
 <CAFjFpRfKNno9tOcWTWmrUeBEB1UXCwrdVHd5XdRfiaLV4WOTwg@mail.gmail.com>
 <7025.1491921708@sss.pgh.pa.us>
 <CAFjFpRdvS56ne6uoy9y3ZRWkFUWEEpCt=w8hwt9wrHWWPYDPeQ@mail.gmail.com>
Comments: In-reply-to Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
	message dated "Tue, 11 Apr 2017 21:48:38 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15196.1491928332.1@sss.pgh.pa.us>
Date: Tue, 11 Apr 2017 12:32:12 -0400
Message-ID: <15197.1491928332@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> OK.  I was trying to be noninvasive, but this does look more sensible.
>> I think this might read better if we inverted the test (so that
>> the outer-join-joinclause-must-be-pushable case would come first).

> Ok. In fact, thinking more about it, we should probably test
> JOIN_INNER explicitly instead of !IS_OUTER_JOIN() since SEMI_JOINS are
> not considered as outer joins and I am not sure how would we be
> treating the quals for those.

No, that's correct as-is --- or at least, if it's not correct, there
are a bunch of other places that are also not correct.

Thinking about this further, though, it seems like a more straightforward
solution to the original problem is to not store quals in a Plan's
fdw_private list in the first place.  Putting them there is at best
useless overhead that the finished plan will have to drag around;
and it's not terribly hard to imagine future changes that would make
having never-processed-by-setrefs.c qual trees in a plan be broken in
other ways.  Can't we use a field in the rel's PgFdwRelationInfo to
carry the remote_exprs forward from postgresGetForeignPlan to
postgresPlanDirectModify?

			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