UPDATE / DELETE fail with "No field named __common_expr_1" when SET or WHERE repeats an expression
维护者通常 1 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 20/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 停滞
- 技术栈
- rust
调研方向
Start by tracing extract_update_assignments and extract_dml_filters in the physical planner, then follow how common subexpression elimination moves expressions into projections. Check the UPDATE and DELETE planning paths against the table provider's schema. Done means the three reproduced statements execute without the missing __common_expr_N schema error and produce the expected row changes.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
An UPDATE or DELETE on an in-memory table fails at planning time with a schema error regarding an internal column when its SET expressions or WHERE clause contain the same expression more than once (for example, COALESCE(c0, 0) on an INT column, where the column is coerced/cast to Int64 twice to match the integer literal):
UPDATE operation on table 't' caused by Schema error: No field named __common_expr_1. Valid fields are c0, c1.
Common subexpression elimination moves the repeated expression into an underlying projection below the UPDATE assignment projection (or below the Filter node). When the physical planner extracts the assignments (extract_update_assignments) and filters (extract_dml_filters) and hands them to the table provider, the provider evaluates them directly against the table's schema, where __common_expr_1 does not exist.
To Reproduce
CREATE TABLE t (c0 INT, c1 VARCHAR);
INSERT INTO t VALUES (1, 'a'), (NULL, 'b');
UPDATE t SET c0 = COALESCE(c0, 0); -- Schema error: No field named __common_expr_1
UPDATE t SET c1 = 'z' WHERE COALESCE(c0, 0) > 0 AND COALESCE(c0, 0) < 5; -- Schema error: No field named __common_expr_N
DELETE FROM t WHERE COALESCE(c0, 0) > 0 AND COALESCE(c0, 0) < 5; -- Schema error: No field named __common_expr_N
Expected behavior
The first UPDATE should update 2 rows ((1, 'a'), (0, 'b')). The second UPDATE should update 1 row, and the DELETE should delete 1 row. The same expressions execute without error in a SELECT.
Additional context
Reproduced on main at commit bc86321 (57.0.0-dev) and with datafusion-python 55.0.0. Found via an automated SQL fuzzer comparing execution plans.
Willingness to contribute
I plan to contribute a fix for this bug independently
- 主要语言
- Rust
- 星标
- 9.6k
- 派生
- 2.6k
- 平均合并
- 3 天 4 小时
- 30 天内合并 PR
- 345
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
apache/datafusion 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
apache/datafusion#27315 · 2 条评论 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
apache/datafusion#27094 · 1 条评论 ·
维护者通常 1 天内回复
-
Substrait consumer doesn't recognise `shift_left` / `shift_right` from functions_arithmetic.yaml可能已有人在做 @jonasHanhan 于 9 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 76/100
apache/datafusion#27059 ·
维护者通常 1 天内回复
-
`ProjectionExprs::project_statistics` computes approximate `Statistics::total_byte_size` ignoring column stats可能已有人在做 @joseph-isaacs 于 10 天前认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 72/100
apache/datafusion#27050 ·
维护者通常 1 天内回复
-
physical-plan: decoding an Unnest or Explain node with an unset field panics可能已有人在做 @geoHeil 于 8 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
apache/datafusion#26999 · 1 条评论 ·
维护者通常 1 天内回复
查看 apache/datafusion 的全部 Issue
相似的 Issue
-
P3
难度 2/5 1-3 小时 新手友好度 70/100
HerringtonDarkholme/hd-lang#1770 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
jonathanong/no-mistakes#3332 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
swc-project/swc-next-issues#310 ·
-
bug
难度 2/5 1-3 小时 新手友好度 72/100
swc-project/swc-ai-issues#653 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
lbjlaq/Antigravity-Manager#3937 ·
维护者通常 1 天内回复