Re: BUG #15613: Bug in PG Planner for Foreign Data Wrappers

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