|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: BUG #15613: Bug in PG Planner for Foreign Data Wrappers|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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
|Next Message||PG Bug reporting form||2019-02-07 21:42:30||BUG #15623: Inconsistent use of default for updatable view|
|Previous Message||PG Bug reporting form||2019-02-07 14:31:51||BUG #15622: Problem with PgAdmin 4 v4.2 - sorry i did not find a correctly section for this problem|