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

Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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