paleolimbot commented on issue #45438: URL: https://github.com/apache/arrow/issues/45438#issuecomment-2676252267
> Is there any way to introduce flexibility? I think so, although I am not sure I have the bandwidth to fix it right this second. The gist of is that the R package uses an `InputType`: https://github.com/apache/arrow/blob/12cdaaafb7a5ba39db81ba6d7e565b8e7a24117e/r/src/compute.cpp#L770 ...that requires an exact match: https://github.com/apache/arrow/blob/12cdaaafb7a5ba39db81ba6d7e565b8e7a24117e/cpp/src/arrow/compute/kernel.h#L200-L202 You could probably use `InputType()` here (i.e., match anything) and write the type checking logic in R (as part of the registration there's a "compute output type from input type", which could error if it gets types it didn't expect. This is likely to be a better error message than the stock one from Arrow C++ about no kernel matching the requested types or whatnot. Alternatively, you could write a `TypeMatcher` subclass and special-case extension types specifically for R UDFs (probably would be helpful for Python UDFs too). Probably other ways too but that's what comes to mind. > My hope is that we (R community) can start working on native arrow objects much more. I think what we might want is a wrapper around arrow memory that is a vctr and can live in a data.frame. The ALTREP in the arrow package and the `nanoarrow_vctr`/`geoarrow_vctr` are both attempts at this and each have some various shortcomings (ALTREP doesn't currently support any of the data types we care about to store spatial data, the nanoarrow_vctr has quite a lot of rough edges). You could probably write one in Rust as well 🙂 -- 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: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
