When the clause s.t1b = s.a is presented to distribute_qual_to_rels() it has form PHV(t1.b) = t2.b. The PHV's ph_eval_at is 4, which is what is returned as varno to pull_varnos(). The other Var in the caluse has varno = 4 already so pull_varnos() returns a SINGLETON relids (b 4). The clause is an equality clause, so it is used to create an Equivalence class. generate_base_implied_equalities_no_const() then constructs the same RestrictInfo again and adds to baserestrictinfo of Rel with relid = 4 i.e. t2's baserestrictinfo. I don't know whether that's the right thing to do.
Well, I think that's what PHVs are supposed to do. Quoting the README:
... Note that even with this restriction, pullup of a LATERAL subquery can result in creating PlaceHolderVars that contain lateral references to relations outside their syntactic scope. We still evaluate such PHVs at their syntactic location or lower, but the presence of such a PHV in the quals or targetlist of a plan node requires that node to appear on the inside of a nestloop join relative to the rel(s) supplying the lateral reference.
I am not sure where we are taking the original bug fix with this investigation. Is it required to fix this problem in order to fix the original problem OR we should commit the fix for the original problem and then investigate this further?
Fair point. This seems a separate problem from the original, so I'm okay we fix them separately.
