What I'm thinking we should do about this, once we detect that this identity is applicable, is to generate *both* forms of Pbc, either adding or removing the varnullingrels bits depending on which form we got from the parser. Then, when we come to forming join paths, use the appropriate variant depending on which join order we're considering. build_join_rel() already has the concept that the join restriction list varies depending on which input relations we're trying to join, so this doesn't require any fundamental restructuring -- only a way to identify which RestrictInfos to use or ignore for a particular join. That will probably require some new field in RestrictInfo, but I'm not fussed about that because there are other fields we'll be able to remove as this work progresses.
Do you mean we generate two RestrictInfos for Pbc in the case of identity 3, one with varnullingrels and one without varnullingrels, and choose the appropriate one when forming join paths? Do we need to also generate two SpecialJoinInfos for the B/C join in the first order, with and without the A/B join in its min_lefthand?
