From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: srinivasan.sa@zohocorp.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15613: Bug in PG Planner for Foreign Data Wrappers
In-reply-to: <5C5BE324.6030601@lab.ntt.co.jp>
References: <15613-092be1be9576c728@postgresql.org>
 <5C51993C.2070606@lab.ntt.co.jp> <19832.1548865557@sss.pgh.pa.us>
 <24678.1548870484@sss.pgh.pa.us> <5C52C769.5090600@lab.ntt.co.jp>
 <19209.1548957996@sss.pgh.pa.us> <5C5A5F75.5040203@lab.ntt.co.jp>
 <5C5ACA1B.3000207@lab.ntt.co.jp> <11975.1549480555@sss.pgh.pa.us>
 <5C5BE324.6030601@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
	message dated "Thu, 07 Feb 2019 16:49:56 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18210.1549550428.1@sss.pgh.pa.us>
Date: Thu, 07 Feb 2019 09:40:28 -0500
Message-ID: <18211.1549550428@sss.pgh.pa.us>
Precedence: bulk

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
>> I propose that we apply this or something much like it to HEAD, and leave
>> the problem of actually working out parameterized foreign joins for later.

> Agreed.  One thing I noticed is this bit in create_foreign_join_path:

> +   /*
> +    * Since the path's required_outer should always include all the rel's
> +    * lateral_relids, forcibly add those if necessary.  This is a bit of a
> +    * hack, but up till early 2019 the contrib FDWs failed to ensure that,
> +    * and it's likely that the same error has propagated into many external
> +    * FDWs.  Don't risk modifying the passed-in relid set here.
> +    */
> +   if (rel->lateral_relids && !bms_is_subset(rel->lateral_relids,
> +                                             required_outer))
> +       required_outer = bms_union(required_outer, rel->lateral_relids);

> I think this would waste cycles.  Do we really need this?  How about 
> just throwing an error instead of doing this, if the joinrel has lateral 
> references?

It ends up being the same thing, because of the test below it, but
at least in HEAD yes this could be simplified.  What I posted is a bit
schizophrenic as to whether it's intended for HEAD or back branches.

Probably, in HEAD there is no good reason to cater for buggy FDWs at
all; the new Asserts in relnode.c are enough, assuming that FDW authors
run some tests while updating to v12.  And if we decide not to backpatch
create_foreign_join_path at all, then it doesn't need a defense like the
above either.  So we just need the above-quoted bit in the back branch
versions of create_foreignscan_path.

			regards, tom lane