jorisvandenbossche commented on PR #42098: URL: https://github.com/apache/arrow/pull/42098#issuecomment-2160328098
The current fix is probably more of a stop-gap, but already wanted to test this on the Python side. There are multiple ways to fix this though, and I am not entirely sure if we have some general guidelines about this. The core issue is that `GetDate32Cast()` does not explicitly create a zero-copy cast kernel for "date32" to "date32". For most other types, such kernel is included for various reasons (eg for time32 it is included because it potentially needs to cast to a different unit). So should we: - Ensure that for every type we always include a cast kernel to itself in the cast table? (do we want to rely on the assumption this is always present?) - Handle this one level up, i.e. in this case handle that in `CanCast` by checking type equality explicitly apart from a kernel being available? (`Cast` itself already handles this case) - Handle this where `CanCast`/`Cast` is being used (like in this PR, although I assume it should be one of the two options above) Actually doing the cast (i.e. not just checking if it is castable with `CanCast`) does already work with the example of "date32", but that is because for input and output type being equal, we never get to getting the actual cast function (`GetCastFunction`) and just return the input as is. So if we follow that logic, I should maybe update `CanCast`? Although on the other hand, people might rely on the fact that if `CanCast` is true, they can get a cast function with `GetCastFunction` (which in this case would then fail, if I don't actually add the "date32" to "date32" zero copy kernel to the table ..). cc @pitrou @felipecrv -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
