Is your feature request related to a problem or challenge? Please describe what you are trying to do.
datafusion-python can serialize a Python scalar UDF inline, by cloudpickling the function together with its schemas and volatility, so a plan referencing a Python UDF round-trips into a process that does not have that function registered. This is what SessionContext.with_python_udf_inlining turns on.
That capability is not reachable from outside the crate. PythonFunctionScalarUDF is pub(crate), and encode_python_scalar_udf / decode_python_scalar_udf in crates/core/src/codec.rs are private; only the try_encode_python_scalar_udf / try_decode_python_scalar_udf wrappers are pub(crate), and they are called from the two codecs this crate installs on every session. A Rust project that already has its own physical extension codec, and wants Python UDFs to travel through it, has to reimplement the cloudpickle framing to stay wire-compatible. Requested in #1678 (review).
Describe the solution you'd like
Extract the inlining behavior into its own LogicalExtensionCodec / PhysicalExtensionCodec implementation and make that type public, rather than exporting two free functions and a struct. Since #1678 made codecs compose, with_python_udf_inlining can then install that codec into the chain instead of being a flag consulted inside PythonLogicalCodec and PythonPhysicalCodec, and an outside consumer can put the same type in its own chain and get the same wire format for free. Suggested independently in #1678 (comment).
A public codec is a better thing to commit to than the current internals. It hides the payload layout, which is versioned and should stay free to change, and it exposes the behavior at the granularity DataFusion already understands.
Describe alternatives you've considered
Marking the existing functions and PythonFunctionScalarUDF pub as they stand. Smaller, but it publishes the payload layout as API, and it does not compose with anything — a caller still has to decide where in its own codec to call them.
Additional context
Depends on #1703, gating pyo3/extension-module, since the crate cannot currently be linked as a plain Rust dependency. Follow-up from #1678.
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
datafusion-python can serialize a Python scalar UDF inline, by cloudpickling the function together with its schemas and volatility, so a plan referencing a Python UDF round-trips into a process that does not have that function registered. This is what
SessionContext.with_python_udf_inliningturns on.That capability is not reachable from outside the crate.
PythonFunctionScalarUDFispub(crate), andencode_python_scalar_udf/decode_python_scalar_udfincrates/core/src/codec.rsare private; only thetry_encode_python_scalar_udf/try_decode_python_scalar_udfwrappers arepub(crate), and they are called from the two codecs this crate installs on every session. A Rust project that already has its own physical extension codec, and wants Python UDFs to travel through it, has to reimplement the cloudpickle framing to stay wire-compatible. Requested in #1678 (review).Describe the solution you'd like
Extract the inlining behavior into its own
LogicalExtensionCodec/PhysicalExtensionCodecimplementation and make that type public, rather than exporting two free functions and a struct. Since #1678 made codecs compose,with_python_udf_inliningcan then install that codec into the chain instead of being a flag consulted insidePythonLogicalCodecandPythonPhysicalCodec, and an outside consumer can put the same type in its own chain and get the same wire format for free. Suggested independently in #1678 (comment).A public codec is a better thing to commit to than the current internals. It hides the payload layout, which is versioned and should stay free to change, and it exposes the behavior at the granularity DataFusion already understands.
Describe alternatives you've considered
Marking the existing functions and
PythonFunctionScalarUDFpubas they stand. Smaller, but it publishes the payload layout as API, and it does not compose with anything — a caller still has to decide where in its own codec to call them.Additional context
Depends on #1703, gating
pyo3/extension-module, since the crate cannot currently be linked as a plain Rust dependency. Follow-up from #1678.