bug: null geometry types error for CLI

[petern48]

I've fixed a few issues with query-ing nulls in previous commits (e.g db5323e and f7a2289), but there's still an existing bug. I don't think either of those commits introduced a new null bug, I think there's just another layer that we need to fix.

Reproduce
Simply boot up the ci

cd sedona-cli/
cargo run

Then run any query while specifying null where it should take a geometry

select st_area(null);
-- External error: Invalid argument: Expected extension type

Using nulls in place of non-geometry values still seem to work (e.g select max(1))

[petern48]

Focusing on other things for now, but I'll circle back to this if time.

[petern48]

The issue is that specific s2geography. The current logic allows the first kernel to operate on the null value. s2geography is registered last, so it takes precedence and is handed these null values which is doesn't handle correctly. Examples of functions it affects are. Unregistering the s2geography functions resulted in these functions working properly.

• st_area
• st_centroid
• st_intersects

I tried adding a null test to the scalar_kernel test for st_area, but it worked successfully. So the bug probably is probably somewhere in our code and how we integrate with s2geography. Not sure where, yet. Narrowed it down a lot though.

I definitely would like to have this fixed before release. There are some obvious quick fixes (e.g registering geography after a different library), but let's see if we can find a more proper fix first.

[paleolimbot]

I have a fix for this in #17 (which pulls s2geography into the default Python build)