alamb commented on PR #13489: URL: https://github.com/apache/datafusion/pull/13489#issuecomment-2499131431
> Bugs happen and these are caught by ValidateDependenciesChecker (example failure [trinodb/trino#22806](https://github.com/trinodb/trino/issues/22806)). That error message is 😍 ``` Suppressed: java.lang.Exception: Current plan: Output[columnNames = [a, _col1, _col2, _col3, _col4, _col5, _col6]] │ Layout: [field:integer, sum:bigint, sum_15:bigint, sum_16:bigint, sum_17:bigint, sum_18:bigint, sum_19:bigint] │ a := field │ _col1 := sum │ _col2 := sum_15 │ _col3 := sum_16 │ _col4 := sum_17 │ _col5 := sum_18 │ _col6 := sum_19 └─ Aggregate[keys = [field]] │ Layout: [field:integer, sum:bigint, sum_15:bigint, sum_16:bigint, sum_17:bigint, sum_18:bigint, sum_19:bigint] │ sum := sum(sum_28) │ sum_15 := sum(sum_29) │ sum_16 := sum(sum_30) │ sum_17 := sum(sum_31) │ sum_18 := sum(sum_32) │ sum_19 := sum(sum_33) └─ Project[] │ Layout: [field:integer, sum_28:bigint, sum_29:bigint, sum_30:bigint, sum_31:bigint, sum_32:bigint, sum_33:bigint] │ sum_28 := (CASE WHEN (field_0 = integer '1') THEN sum_21 ELSE bigint '0' END) │ sum_29 := (CASE WHEN (field_0 = integer '2') THEN sum_23 ELSE CAST(field_1 AS bigint) END) │ sum_30 := (CASE WHEN (field_0 = integer '3') THEN sum_23 ELSE CAST(field_2 AS bigint) END) │ sum_31 := (CASE WHEN (field_0 = integer '4') THEN sum_25 ELSE bigint '0' END) │ sum_32 := (CASE WHEN (field_0 = integer '5') THEN sum_27 ELSE bigint '0' END) │ sum_33 := (CASE WHEN (field_0 = integer '6') THEN sum_23 ELSE CAST(field_3 AS bigint) END) └─ Aggregate[type = FINAL, keys = [field_0, field]] │ Layout: [field_0:integer, field:integer, sum_21:bigint, sum_23:bigint, sum_25:bigint, sum_27:bigint] │ sum_21 := sum(sum_34) │ sum_23 := sum(sum_35) │ sum_25 := sum(sum_36) │ sum_27 := sum(sum_37) └─ LocalExchange[partitioning = HASH, arguments = [field::integer]] │ Layout: [field_0:integer, field:integer, sum_34:bigint, sum_35:bigint, sum_36:bigint, sum_37:bigint] └─ Aggregate[type = PARTIAL, keys = [field_0, field]] │ Layout: [field_0:integer, field:integer, sum_34:bigint, sum_35:bigint, sum_36:bigint, sum_37:bigint] │ sum_34 := sum(expr_20) │ sum_35 := sum(expr_22) │ sum_36 := sum(expr_24) │ sum_37 := sum(expr_26) └─ Values[] Layout: [field_0:integer, field:integer, expr_20:bigint, expr_22:bigint, expr_24:bigint, expr_26:bigint] (integer '1', integer '1', bigint '1', bigint '0', bigint '1', bigint '1') (integer '2', integer '2', bigint '2', bigint '0', bigint '2', bigint '2') (integer '3', integer '3', bigint '3', bigint '0', bigint '3', bigint '3') at io.trino.sql.planner.sanity.PlanSanityChecker.validate(PlanSanityChecker.java:120) ... 17 more ``` > With ordinal-based, every such bug would be incorrect but potentially executable plan, so instead of clear error, it could produce incorrect results. Why would we prefer that? I agree -- an error vs incorrect results sounds like the right tradeoff to me -- 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: github-unsubscr...@datafusion.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For additional commands, e-mail: github-h...@datafusion.apache.org
