[
https://issues.apache.org/jira/browse/CALCITE-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1170.
----------------------------------
Resolution: Fixed
Fix Version/s: 1.8.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/3ba595a1. Thanks
for the PR, [~seanhychu]!
> Allow SqlSetOperator to be overridden, as a regular SqlOperator can
> -------------------------------------------------------------------
>
> 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
> Fix For: 1.8.0
>
>
> 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)
