A gap in preventing bogus parameterizations in a798660ebe3

Hi,

The second bug / assert failure I ran into when running the randomized
join generator seems to be hitting a gap in a798660ebe3:

Defend against bogus parameterization of join input paths.

A trivial reproducer for this is:

CREATE TABLE t (a integer, b integer);
CREATE INDEX ON t (a, b);

EXPLAIN
SELECT 1 FROM t t1
WHERE t1.a IN (SELECT t2.a
FROM t t2
LEFT JOIN t t3 ON (t2.a = t3.a)
LEFT JOIN (t t4 LEFT JOIN t t5 ON (t4.a = t5.a))
ON (t3.a = t4.a)
WHERE coalesce(t5.b, 0) = t2.b);

Which trips over this asssert in get_baserel_parampathinfo():

Assert(!bms_overlap(joinrel->relids, required_outer));

This is not an area I know very well, but it seems the defense added by
a798660ebe3 considers only sjinfo->ojrelid. But that does not seem to be
enough for joins pushed down through identity 3. IIUC those are added to
ojrelid only for the join that completes it, and so the sjinfo->ojrelid
may not be entirely "up to date", and the parameterized paths have the
same issue as those rejected by a798660ebe3.

The attached patch fixes that by adding a new JoinPathExtraData field
ojrelids, and calculating it from joinrel/inner/outer like this:

if (sjinfo->ojrelid != 0)
{
extra.ojrelids = bms_difference(joinrel->relids, outerrel->relids);
extra.ojrelids = bms_del_members(extra.ojrelids, innerrel->relids);
extra.ojrelids = bms_add_member(extra.ojrelids, sjinfo->ojrelid);
}

There's a comment in add_paths_to_joinrel explaining why I think this is
correct, but is it? Perhaps I'm forgetting something.

Also, the new field would be a problem for backpatching (the problem
exists since 16), and a new field might break ABI. Perhaps it'd be
better to just calculate it in the handful of places that need it.

regards

--
Tomas Vondra