On Sat, Sep 6, 2025 at 1:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I was not aware of outer_join_rels, so thank you for pointing it out.
> > However, consider this query:
>
> > select 1 from pg_class a inner join pg_class b on a.relfilenode = b.relfilenode;
>
> > Here, we end up with a three-item range table: one for a, one for b,
> > and one for the join. But the join is not an outer join, and does not
> > appear in root->outer_join_rels. Therefore, I'm not sure we can rely
> > on outer_join_rels in this scenario.
> Plain (not-outer) joins will never be included in a relid set in the
> first place.
Exactly. Non-outer joins wouldn't cause Vars to become null, so we
never include them in the joinrel's relids.
BTW, I'm wondering if we can take outer join relids into account in
assert_join_preserves_scan_rtis(), which could make the check more
useful. A joinrel's relids consists of three parts: the outer plan's
relids, the inner plan's relids, and the relids of outer joins that
are calculated at this join. We already have the first two. If we
can find a way to determine the third, we'd be able to assert that:
outer_relids U inner_relids U outerjoin_relids == joinrel->relids
Determining the third part can be tricky though, especially due to
outer-join identity 3: the "outerjoin_relids" of one outer join might
include more than one outer join relids. But I think this is till
doable.
(This may not be useful for your overall goal in this patchset, so
feel free to ignore it if it's not of interest.)
- Richard
