Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-1170

Allow SqlSetOperator to be overridden, as a regular SqlOperator can

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8.0
    • Component/s: core
    • Labels:
      None

      Description

      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

        Issue Links

          Activity

          Hide
          seanhychu Sean Hsuan-Yi Chu added a comment -
          Show
          seanhychu Sean Hsuan-Yi Chu added a comment - Pull request: https://github.com/apache/calcite/pull/215
          Hide
          seanhychu Sean Hsuan-Yi Chu added a comment -

          Julian Hyde Can you please help see if this proposal makes sense? Thanks so much.

          Show
          seanhychu Sean Hsuan-Yi Chu added a comment - Julian Hyde Can you please help see if this proposal makes sense? Thanks so much.
          Hide
          julianhyde Julian Hyde added a comment -

          Since set-operators are relational operators, not scalar operators, I would not fight very hard to make them follow the usual validation process for scalar operators. There is no real need for "user defined relational operators" in the same way that we have lots of user-defined scalar operators. My natural inclination would be to override a method in the validator rather than to change the behavior of the operator.

          That said, do all tests pass after this change? If they do I would be inclined to accept.

          Show
          julianhyde Julian Hyde added a comment - Since set-operators are relational operators, not scalar operators, I would not fight very hard to make them follow the usual validation process for scalar operators. There is no real need for "user defined relational operators" in the same way that we have lots of user-defined scalar operators. My natural inclination would be to override a method in the validator rather than to change the behavior of the operator. That said, do all tests pass after this change? If they do I would be inclined to accept.
          Hide
          seanhychu Sean Hsuan-Yi Chu added a comment -

          Yes, it passed all the tests.

          Show
          seanhychu Sean Hsuan-Yi Chu added a comment - Yes, it passed all the tests.
          Show
          julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/3ba595a1 . Thanks for the PR, Sean Hsuan-Yi Chu !
          Hide
          julianhyde Julian Hyde added a comment -

          Resolved in release 1.8.0 (2016-06-13).

          Show
          julianhyde Julian Hyde added a comment - Resolved in release 1.8.0 (2016-06-13).

            People

            • Assignee:
              julianhyde Julian Hyde
              Reporter:
              seanhychu Sean Hsuan-Yi Chu
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development