github-actions[bot] commented on code in PR #70345:
URL: https://github.com/apache/doris/pull/70345#discussion_r4545504363
##########
fe/fe-core/src/main/java/org/apache/doris/catalog/FunctionToThriftConverter.java:
##########
@@ -158,6 +158,9 @@ private static TFunction toThriftBase(Function fn, Type
realReturnType, Type[] r
tName.setFunctionName(fn.getFunctionName().getFunction());
tfn.setName(tName);
tfn.setBinaryType(toThriftBinaryType(fn.getBinaryType()));
+ if (fn.getBinaryType() == Function.BinaryType.PYTHON_UDF) {
+ tfn.setEnablePythonUdfDatetimeWithoutTimezone(true);
Review Comment:
[P1] Negotiate naive DATETIME before enabling it on mixed backends
This sets the new representation for every Python UDAF even while a query
can still run on old BEs, which ignore the unknown optional field. A
distributed DATETIME maximum UDAF that stores its input datetime in
aggregate_state therefore produces timezone-aware partial states on old BEs and
naive states on new BEs. UDAFStateManager serializes these values with pickle
and passes them unchanged to the user merge method, so merging the second
partial raises TypeError when it compares aware and naive datetimes. The flag
needs to remain disabled until every participating BE supports the new
representation, or the intermediate-state protocol needs an explicit
compatibility mechanism; the optional field alone does not protect this upgrade
direction.
##########
be/src/exprs/aggregate/aggregate_function_python_udaf.cpp:
##########
@@ -217,6 +211,9 @@ Status AggregatePythonUDAF::open() {
_func_meta.input_types = argument_types;
_func_meta.return_type = _return_type;
_func_meta.client_type = PythonClientType::UDAF;
+ _func_meta.datetime_naive = PythonUDFMeta::uses_naive_datetime(_fn);
+ _func_meta.timezone = state->timezone();
Review Comment:
[P1] Preserve the legacy DATETIME timezone when the flag is absent
With an old FE the flag is absent, but these assignments still replace the
previous fixed +08:00 DATETIME mapping with the session timezone. During a
BE-first upgrade in a UTC session, a maximum UDAF can receive 2026-10-10 10:00
from an old BE as 10:00+08:00 (02:00Z) and 09:00 from a new BE as 09:00+00:00
(09:00Z). Both states are aware datetimes and their raw pickle merge selects
09:00, producing an incorrect SQL DATETIME maximum. Gating the new FE flag does
not fix this case: the absent/false fallback must preserve the fixed legacy
DATETIME zone consistently in schemas, encoding and decoding, while keeping
TIMESTAMPTZ session semantics separate.
--
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]
