fix(ir): fix window boundaries being forcefully casted

[chloeh13q]

Description of changes

Fix issue #8368

Issues closed

Resolves #8368

[cpcloud]

Just curious, does removing these lines not address the problem?

[chloeh13q]

I tried doing that, and that breaks the windowing logic for at least some backends. For example, if the window is something like -ibis.interval(seconds=20), 0 where one of the boundary is an interval and the other one is an int (most commonly in the case of 0), it ends up erroring out when executed on the backend (e.g. pandas). So essentially, instead of baking the casting logic into the IR we would move the casting logic out to backends where casting is necessary, which is doable but seems like it may be a more complex solution

[kszucs]

I dislike introducing is_same_base_type() api just to overcome this issue. There are basically two kind of inputs are supported here, numeric and interval. Could we spell out all combinations instead, something like:

def _maybe_cast_boundaries(self, start, end):
    if start.dtype.is_interval() and end.dtype.is_numeric():
        return start, ops.Cast(end, start.dtype)
    elif start.dtype.is_numeric() and end.dtype.is_interval():
        return ops.Cast(start, end.dtype), end
    else:
        return start, end

Also just check for rlz.comparable(start, end) during the WindowFrame validation.

[chloeh13q]

Sure, that's fair.

Also just check for rlz.comparable(start, end) during the WindowFrame validation.

I think this would yield the same result as above, when we were to remove the _maybe_cast_boundaries() logic entirely. At this point it should be required that window start and window end are both numeric or both intervals.

[kszucs]

Indeed, then we should validate for that.

[chloeh13q]

@cpcloud Thanks for the suggestion! I implemented the changes.

[kszucs]

LGTM, thanks Chloe!