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 07:58:25 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15211505#comment-15211505 ]
Sean Hsuan-Yi Chu commented on CALCITE-1170:
--------------------------------------------
Pull request:
https://github.com/apache/calcite/pull/215
> 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)