[CALCITE-2082] Do not store types or type factories inside operators

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.26.0
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 08/Dec/17 23:07
• Updated: 06/Oct/20 17:16
• Resolved: 21/Aug/20 06:33

Description

Do not store types (RelDataType) or type factories (RelDataTypeFactory) in SqlOperator instances.

Rationale: a SqlOperator has a lifetime that spans many statements; but a type factory is only for one statement, and each type belongs to that factory. We want to share SqlOperator instances across connections, therefore we need to create them before there is a type factory.

Typically, a method that returns a type should have a type factory argument with which to create it.

The current situation is technical debt. There are a couple of pieces of code tagged with this case number; see the fix to CALCITE-2072.

In particular:

• Remove method List<RelDataType> SqlOperator.getParamTypes();
• Remove RelDataTypeFactory argument from SqlUserDefinedAggFunction constructor, and remove its typeFactory field.

We will add interface SqlOperandMetadata extends SqlOperatorTypeChecker, which has new methods List<RelDataType>> paramTypes(RelDataTypeFactory) and List<String> paramNames().

This interface will typically be implemented only for user-defined functions. Unlike SQL built-in functions, UDFs have a fixed set of parameters (although some of them may be optional), and the parameters have names.

In interface SqlOperandTypeChecker, add method boolean isFixedParameters(). Will typically return true for UDFs, false for built-in functions. Returns false for table window functions (e.g. HOP), even though these have named parameters (which tends to make them look a bit like UDFs).

Issue Links

• is related to: CALCITE-4171 Support named parameters for table window functions