amaliujia commented on a change in pull request #1587: [CALCITE-3272] Support TUMBLE as Table Valued Function including an enumerable implementation, stream.iq and DESCRIPTOR URL: https://github.com/apache/calcite/pull/1587#discussion_r358637616
########## File path: core/src/main/java/org/apache/calcite/sql/SqlDescriptorOperator.java ########## @@ -0,0 +1,73 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to you under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.calcite.sql; + +import org.apache.calcite.rel.type.RelDataType; +import org.apache.calcite.sql.type.SqlTypeName; +import org.apache.calcite.sql.validate.SqlValidator; +import org.apache.calcite.sql.validate.SqlValidatorScope; + +import java.util.List; + +import static org.apache.calcite.util.Static.RESOURCE; + + +/** + * <p>DESCRIPTOR appears as an argument in a function. DESCRIPTOR accepts a list of + * identifiers that represent a list of names. The interpretation of names is left + * to the function. + * + * <p>A typical syntax is DESCRIPTOR(col_name, ...). + * + * <p>An example is a table-valued function that takes names of columns to filter on. + */ +public class SqlDescriptorOperator extends SqlOperator { + public SqlDescriptorOperator() { + super("DESCRIPTOR", SqlKind.DESCRIPTOR, 100, 100, null, null, null); + } + + @Override public SqlSyntax getSyntax() { + return SqlSyntax.FUNCTION; + } + + @Override public RelDataType deriveType(SqlValidator validator, + SqlValidatorScope scope, SqlCall call) { + List<SqlNode> sqlIdentifiers = call.getOperandList(); + + // validate column names that are specified by DESCRIPTOR. + for (SqlNode node : sqlIdentifiers) { + if (!(node instanceof SqlIdentifier)) { + throw SqlUtil.newContextException(node.getParserPosition(), + RESOURCE.aliasMustBeSimpleIdentifier()); + } + + SqlIdentifier identifier = (SqlIdentifier) node; Review comment: This is tricky for `DESCRIPTOR`. After checking existing type checkers, I think Calcite' `OperandTypeChecker` and `checkOperandTypes` are designed to verify the operand types. For example. It checks if MOD's operands are `INTEGER`. Back to `DESCRIPTOR`, there is no really `type` associated with column names. For example, `descriptor(key_column)`, we don't know what's the type of key_column, thus type checker checks nothing. There is a need to verify if columns can be found, which can be done in either `deriveType` or `checkOperandTypes`. In the full version of `DESCRIPTOR`, SQL standards allows user provide a type, e.g. `descriptor(key_column INTEGER)`, which can be used for type checking, say the column name can be resolved and the corresponding column found from the table is also `INTEGER`. The full version should override `checkOperandTypes` for sure. Given the current status of `DESCRIPTOR`, I incline to keep the name resolution in `driveType` as it's already implemented. When we have the full version of `DESCRIPTOR`, we should make everything done in type checker. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
