You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (Jira)" <ji...@apache.org> on 2019/10/15 23:46:00 UTC
[jira] [Commented] (CALCITE-3399) RelFieldTrimmer trim fields for
UNION, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL
[ https://issues.apache.org/jira/browse/CALCITE-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952392#comment-16952392 ]
Julian Hyde commented on CALCITE-3399:
--------------------------------------
The current title "RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL" doesn't say whether trimming fields is desired or undesired behavior. How about "Field-pruning for set operators (except UNION ALL) changes query semantics"?
> RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL
> -----------------------------------------------------------------------------------
>
> Key: CALCITE-3399
> URL: https://issues.apache.org/jira/browse/CALCITE-3399
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: jin xing
> Assignee: jin xing
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *RelFieldTrimmer#trimFields* provides functionality to trim fields for *UNION, UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL;*
> But *UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL* works by checking duplication. Column pruning on inputs of *SetOp* might lead to different semantics.
>
> Take below example for illustration
> {code:java}
> emp0:
> name, deptno
> "A", 0
> "B", 1
> emp1:
> name, deptno
> "C", 0
> "D", 2
> select deptno from
> (select name, deptno from emp0
> intersect
> select name, deptno from emp1)
> {code}
> Run above Sql on emp0 and emp1, result is not empty if trim fields on inputs of INTERSECT, but result is empty if DO NOT trim fields on inputs of INTERSECT
--
This message was sent by Atlassian Jira
(v8.3.4#803005)