uchenily commented on code in PR #57253:
URL: https://github.com/apache/doris/pull/57253#discussion_r2454205738
##########
be/src/vec/functions/function_date_or_datetime_computation.h:
##########
@@ -124,11 +127,34 @@ ADD_TIME_FUNCTION_IMPL(AddWeeksImpl, weeks_add, WEEK);
ADD_TIME_FUNCTION_IMPL(AddMonthsImpl, months_add, MONTH);
ADD_TIME_FUNCTION_IMPL(AddYearsImpl, years_add, YEAR);
+template <PrimitiveType PType>
+struct AddDaySecondImpl {
+ static constexpr PrimitiveType ArgPType = PType;
+ static constexpr PrimitiveType ReturnType = PType;
+ static constexpr PrimitiveType IntervalPType = PrimitiveType ::TYPE_INT;
+ static constexpr PrimitiveType IntervalPRealType = TYPE_STRING;
Review Comment:
This is actually a compromise solution. We introduced the IntervalPRealType
field to handle cases like AddDaySecondImpl where the delta value passed during
the execution of the execute method requires type conversion (StringRef →
Integer). (So we cannot directly use the `ADD_TIME_FUNCTION_IMPL` macro to
generate the code).
If we hadn't introduced the `IntervalPRealType` field and instead set
`IntervalPType = TYPE_STRING`, then in
`FunctionDateOrDateTimeComputation::execute_impl`, we would need to handle
TYPE_STRING cases for all three scenarios: vector-vector, vector-const, and
const-vector. While the vector-const scenario would be simple to handle, but
handling other scenarios will be complex, as we would need to modify all
execute methods to support the TYPE_STRING type.
--
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]
