Closed jcrist closed 1 week ago
How would someone compute a NULL
-preserving equality with this change? It seems like it would no longer be possible to do that.
For the semantics you've defined here, you can already do this with a.identical_to(NA)
.
Oh, it looks like we're doing that already (as you note in the description), nevermind!
Previously we coerced
co == None
toIdenticalTo(col, None)
, but wouldn't do so foribis.NA
(resulting in that compiling asEquals(col, None)
(which would result in incorrect SQL). This PR fixes this eager branch to handle any null literal, and compiles it the same asisnull
/notnull
(usuallycol IS NULL
) rather than the more verbosecol IS NOT DISTINCT FROM NULL
that usingIdenticalTo
would result in.Other options for this fix would be to:
Equals
and use a rewrite rule to rewrite these cases. I opted against this since we'd have to have the same detection logic later, and this rewrite rule would be applied for every backend. Honestly havingEquals.__new__
/NotEquals.__new__
optionally returnIsNull
/NotNull
would be cleaner IMO, but that's harder to do with our operation infrastructure.Equals
, and branch when compiling to generate the proper SQL there. This is a bit harder to do, and also would need to be implemented for dataframe backends socol == None
would still use the properisnull
call.