fix(api): treat col == None
or col == ibis.NA
as col.isnull()
#9114
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.