Lazy join_where between Int64 and UInt64 attempts cast to Float64 and fails with SchemaError

[nameexhaustion]

Checks

• I have checked that this issue has not already been reported.
• I have confirmed this bug exists on the latest version of Polars.

Reproducible example

(
    pl.Series([1], dtype=pl.Int64)
    .to_frame()
    .lazy()
    .join_where(
        pl.Series([1], dtype=pl.UInt64).to_frame().lazy(),
        pl.col("") == pl.col("_right"),
    )
    .collect()
)

Log output

polars.exceptions.SchemaError: datatypes of join keys don't match - ``: f64 on left does not match ``: u64 on right

Issue description

There is a cast to Float64 being inserted somewhere that should not be inserted. This should instead cast to Int128.

Expected behavior

Succeeds without failing

Installed versions

1.21.0

[lukemanley]

It looks like this occurs here:

polars/crates/polars-core/src/utils/supertype.rs

Line 234 in e950592

(Int64, UInt64) => Some(Float64), // Follow numpy

Here is a related example where adding an Int64 and a UInt64 results in a Float64 rather than a Int128:

pl.select(pl.lit(1, pl.Int64) + pl.lit(1, pl.UInt64))

# shape: (1, 1)
# ┌─────────┐
# │ literal │
# │ ---     │
# │ f64     │
# ╞═════════╡
# │ 2.0     │
# └─────────┘

Would changing this to return Int128 be considered a breaking change?

[nameexhaustion]

Nice debugging

Would changing this to return Int128 be considered a breaking change?

• For this I've opened an issue at Change supertype of <signed integer type>, UInt64 from Float64 to Int128 #21065

I am in favor of doing this, but I would also consider it a breaking change as it would change the behavior of some queries.

We don't need to change it to fix the current issue - type coercion of join keys should not be hitting that codepath.