[Rust] Boolean AND/OR kernels should follow sql behaviour regarding null values

[asfimport]

The AND/OR boolean kernels currently have the same null handling as other binary expressions, if either the left or right input is NULL then the result will be NULL. The standard sql behaviour is different:

OR: If one input is TRUE then the result will be TRUE even if the other input is NULL

AND: If one input is FALSE then the result will be FALSE regardless of the other input

This behaviour makes sense if you think of NULL as meaning UNKNOWN.

Reporter: Jörn Horstmann / @jhorstmann
Assignee: Christoph Schulze / @ch-sc

PRs and other links:

• GitHub Pull Request #9772

_{Note: This issue was originally created as ARROW-11973. Please see the migration documentation for further details.}

[asfimport]

Jörn Horstmann / @jhorstmann:
@alamb @andygrove FYI and do you think anyone relies on the current behaviour?

[asfimport]

Andrew Lamb / @alamb:
@jhorstmann I prefer to follow SQL whenever possible. The other thing we should review is consistency with the Arrow C++ kernels. I am supportive of making the Rust implementation more consistent with one / both of them

[asfimport]

Joris Van den Bossche / @jorisvandenbossche:

The other thing we should review is consistency with the Arrow C++ kernels.

In C++, both options are available as different kernels: "or" and "or_kleene", etc

[asfimport]

Jorge Leitão / @jorgecarleitao:
 

I agree with having two kernels on the Rust crate and offer the SQL-compliant implementation on the DataFusion side.

In general I prefer to not have to follow a specific compliance on the arrow crate, and defer these to any engine that follows a query specification.

[asfimport]

Daniël Heres / @Dandandan:
In PostgreSQL (the dialect we target) the default is what we currently have implemented.

SELECT TRUE AND NULL;

NULL
SELECT TRUE OR NULL;
NULL

I am all for having optionally different implementations in Arrow (for supporting different semantics / systems) though - but for DataFusion side it makes sense to think about what kind of behavior we want?
I think kleene could be somewhat more efficient in some cases - as it could short-circuit / doesn't need to check for possible NULLs.

[asfimport]

Andrew Lamb / @alamb:
Issue resolved by pull request 9772
#9772