timsaucer commented on code in PR #16053:
URL: https://github.com/apache/datafusion/pull/16053#discussion_r2102451109
##########
datafusion/physical-expr/src/expressions/literal.rs:
##########
@@ -34,15 +36,37 @@ use datafusion_expr_common::interval_arithmetic::Interval;
use datafusion_expr_common::sort_properties::{ExprProperties, SortProperties};
/// Represents a literal value
-#[derive(Debug, PartialEq, Eq, Hash)]
+#[derive(Debug, PartialEq, Eq)]
pub struct Literal {
value: ScalarValue,
+ metadata: Option<HashMap<String, String>>,
Review Comment:
I think there are two compelling arguments for keeping the metadata on the
`Literal` rather than the `ScalarValue`
- Does not require a change to the protobuf definitions. I haven't tested
this thoroughly yet, but I think if we put the metadata on the scalar value we
would need more breaking changes on the conversion between protobuf and
internal types, basically needing to pass the schema around. This isn't a
deal-breaker but I could see pain points for some users.
- The match statements like @tobixdev points out. I've also seen a growing
usage of things like `let ScalarValue::Utf8(my_string) = val else { return
exec_error!("invalid scalar value") }` which would not survive a case where
they really do have a valid value.
--
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]
