getChan commented on issue #24133: URL: https://github.com/apache/datafusion/issues/24133#issuecomment-5229984683
I think there are three possible places to model the constant/literal-argument requirement: | Design | Pros | Cons | | --- | --- | --- | | Add `is_scalar` / `is_literal` to `Coercion` | Small implementation change; reuses the existing coercible-signature flow | Mixes type coercion with expression/value constraints; `Coercion` becomes responsible for more than type conversion | | Add argument constraints to `Signature` | Keeps type coercion separate from value constraints; clear for functions where the same argument constraint applies to every accepted type alternative | Less suitable if different `OneOf` alternatives need different constraints | | Add constraints to the argument definitions inside `TypeSignature` | Most expressive; constraints can vary per signature alternative and per argument | Larger API and migration cost; more implementation work | For the current use cases (`arrow_cast`, `arrow_try_cast`, and `date_part`), the literal requirement appears to be common across all accepted alternatives. Therefore, an argument-constraint member on `Signature` seems like the cleanest option for this issue. If we want to support alternatives with different literal requirements in the future, the constraint should instead live with each argument in the `TypeSignature` alternative. Also, the current check is specifically for `Expr::Literal`, so `literal` or `constant` may be a more precise name than `scalar`. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
