LakshSingla commented on code in PR #15316: URL: https://github.com/apache/druid/pull/15316#discussion_r1381473076
########## sql/src/main/java/org/apache/calcite/sql/type/CastedLiteralOperandTypeCheckers.java: ########## @@ -0,0 +1,164 @@ +/* + * 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. + */ + +//CHECKSTYLE.OFF: PackageName - Must be in Calcite + +package org.apache.calcite.sql.type; + +import com.google.common.collect.ImmutableList; +import org.apache.calcite.sql.SqlCall; +import org.apache.calcite.sql.SqlCallBinding; +import org.apache.calcite.sql.SqlLiteral; +import org.apache.calcite.sql.SqlNode; +import org.apache.calcite.sql.SqlUtil; +import org.apache.calcite.sql.parser.SqlParserPos; +import org.apache.calcite.util.Static; +import org.apache.druid.error.DruidException; + +import java.math.BigDecimal; + +public class CastedLiteralOperandTypeCheckers Review Comment: > Nit: What are the implications of this during the Calcite upgrade? Since this code is a copy & paste from the Calcite, on upgrading Calcite (major version), it'd be good to check if anything major has changed it in the code. > Or better yet move them to Apache Calcite? Casting a literal isn't a very valid operation. Either the type-checking code should allow the dynamic parameters (in Calcite), or we need a different way to replace the parameters. This is kind of a hacky fix, which allows `CAST` on literals using the type checker in the code. The real fix would be to allow the users to not write dynamic parameters with CAST. The only downside with this approach, and Druid 28 is that since we are suggesting users do a CAST(? AS TYPE) while writing JDBC queries, we would need to support this method even if we fix the real reason because users might be writing the queries with an explicit cast. However, that cannot be helped by this fix. This just allows what users have been advised to pass through the Druid's functions. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
