You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "Sean Hsuan-Yi Chu (JIRA)" <ji...@apache.org> on 2016/03/25 07:46:25 UTC

[jira] [Created] (CALCITE-1170) Set Operator is not overridden as the usual SqlOperator

Sean Hsuan-Yi Chu created CALCITE-1170:
------------------------------------------

             Summary: Set Operator is not overridden as the usual SqlOperator
                 Key: CALCITE-1170
                 URL: https://issues.apache.org/jira/browse/CALCITE-1170
             Project: Calcite
          Issue Type: Improvement
          Components: core
            Reporter: Sean Hsuan-Yi Chu
            Assignee: Sean Hsuan-Yi Chu


Calcite allows operators in SqlStdOperatorTable to be overridden when users would like to have their customized operators to be used instead. (see [CALCITE-1062] as an example).

If this logic is applied to SqlSetOperator, the systems which leverage Calcite can define their own output types (based on customized implicit casting rule) for Union-All, Intersect, etc. 

Below is more implementation-oriented:
As is shown here [1], as opposed to calling deriveType(), the code calls validateOperands(). By doing so, the logic of overriding SqlOperator is skipped. 

However, if we call deriveType() here, the logic of overriding SqlOperator will happen and validateOperands() will be called right afterwards [2]. 

[1] https://github.com/apache/calcite/blob/4c7f5c20a04b4a4e736a16f801d8b5e6eded48cc/core/src/main/java/org/apache/calcite/sql/validate/SetopNamespace.java#L105

[2]
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlOperator.java#L508



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)