Re: Wrong results due to missing quals

I wrote:
> ... Another idea is that maybe we need another
> RestrictInfo field that's directly a set of OJ relids that this clause
> can't be applied above.  That'd reduce clause_is_computable_at to
> basically a bms_intersect test which would be nice speed-wise.  The
> space consumption could be annoying, but I'm thinking that we might
> only have to populate the field in clone clauses, which would
> alleviate that issue.

I tried this and it seems to work all right: it fixes the example
you showed while not causing any new failures.  (Doesn't address
the broken join-removal logic you showed in the other thread,
though.)

While at it, I also changed make_restrictinfo to treat has_clone
and is_clone as first-class citizens, to fix the dubious coding in
equivclass.c that I mentioned at [1].

			regards, tom lane

[1] https://www.postgresql.org/message-id/395264.1684698283%40sss.pgh.pa.us