Re: possible bug in 8.4

Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Yeah.  NOT IN does not have the right semantics to become an antijoin.

> If we noticed that the columns in the subquery are all guaranteed to be not
> null could we do it then?

I think you'd also have to know that the outer-query value isn't null,
plus assume that the comparison operator can't return null for two
non-nulls (but we already assume that for btree/hash equality I think).

As you said, this would never have been safe before plan invalidation,
but it might be doable now.
        regards, tom lane