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

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

     [ https://issues.apache.org/jira/browse/CALCITE-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Hsuan-Yi Chu updated CALCITE-1170:
---------------------------------------
    Assignee: Julian Hyde  (was: Sean Hsuan-Yi Chu)

> 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: Julian Hyde
>
> 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)