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

Avoid transformations to Enumerable nodes for custom SqlOperators

    XMLWordPrintableJSON

    Details

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

      Description

      Most Enumerable converter rules apply a transformation as soon as the RelNode class and its convention match those defined by the rule. However, there are use-cases that we would like to restrict the matches even further to avoid generating unimplementable plans that will fail at runtime.

      The most prominent example comes from extending the standard operator set with new SqlOperator s that appear in filters and projections as part of a row expression (RexNode). If we use the default instance of the EnumerableCalcRule we might end-up with a plan that will fail at runtime since the new operator is not handled by the Enumerable convention. Most likely there is a RelNode in another convention that can handle this new operator.

      We could avoid such undesirable transformations by allowing instantiations of the Enumerable converter rules with user-defined predicates. This also means adding public constructors to the rules that currently they do not have one.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                zabetak Stamatis Zampetakis
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: