kumarUjjawal commented on code in PR #24166:
URL: https://github.com/apache/datafusion/pull/24166#discussion_r3742712667


##########
datafusion/physical-plan/src/aggregates/mod.rs:
##########
@@ -2139,8 +2139,32 @@ impl ExecutionPlan for AggregateExec {
     ) -> Result<Option<datafusion_proto_models::protobuf::PhysicalPlanNode>> {
         use datafusion_proto_models::protobuf;
 
-        let input = ctx.encode_child(self.input())?;
-        let group_by = self.group_expr();
+        // Exhaustive destructure: adding a field to `AggregateExec` without
+        // deciding how it is serialized is a compile error, not a silent
+        // round-trip gap.
+        let Self {
+            mode,
+            group_by,
+            aggr_expr,
+            filter_expr,
+            limit_options,
+            input,
+            // Derived at construction by `create_schema` from `input_schema`,

Review Comment:
   I don't think schema is always safely derived here. `with_new_aggr_exprs` 
and `with_new_children` preserve the existing schema through 
`try_new_with_schema` specifically because rebuilding it after rewriting 
aggregate expressions can change field names. However, deserialization calls 
`AggregateExec::try_new` which rebuilds the schema. Is this an already existing 
issue?



-- 
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]

Reply via email to