A possible solution would be for the validator to represent: * a type inferred for each expression, * a type inferred for each argument of a SqlCall (does not currently exist)
A validator post-pass would insert casts as follows: If the type of an argument expression does not match the expected type of the SqlCall argument an explicit cast is inserted. For example, consider an expression like SELECT 5 + (CAST 5 as BIGINT) The expression is a RexCall with two arguments. After type inference, the inferred types are as follows: * 5 -> type is INT * (CAST 5 AS BIGINT) -> type is BIGINT * SqlCall(+) -> type is BIGINT * SqlCall.argument_type[0] -> type is BIGINT * SqlCall.argument_type[1] -> type is BIGINT Because the argument_type[0] != operands[0].type, the expression is rewritten as SqlCall(CAST(5 AS BIGINT), CAST(5 AS BIGINT)). The expressions are immutable during type inference, and only a subsequent visitor rewrites the tree in one pass. Mihai ________________________________ From: Julian Hyde <jhyde.apa...@gmail.com> Sent: Monday, September 23, 2024 11:39 AM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Re: Discussion: Calcite's standard for function argument conversion There was a discussion a while ago where we decided that type resolution should decide which overload of the method was being called - and therefore the type that each argument needs to be converted to. And it should decide how to convert the argument to the parameter type. (I use the words ‘argument’ and ‘parameter’ in their technical sense [1].) One kind of conversion is widening, e.g. converting a SMALLINT argument to INTEGER parameter type. This is widening because every valid SMALLINT value maps to one INTEGER value. Another kind of conversion is coercion, e.g. converting a CHAR or VARCHAR argument to a DATE parameter type. This is coercion because some strings (e.g. ‘2024-09-23’ and ‘2024-9-23’) correspond to valid dates, and others (e.g. ‘Hello’) do not. I do not remember where that discussion ended up. I thought we’d end up implementing it by storing the ‘how to convert’ information in the SqlValidator along with the inferred parameter type. Julian PS Please use ‘[DISCUSS]’ rather than ‘Discussion:’ in the message subject. Standards are useful. [1] https://www.educative.io/answers/parameter-vs-argument > On Sep 21, 2024, at 9:35 AM, Cancai Cai <caic68...@gmail.com> wrote: > > Hello, everyone in the calcite community. > > I encountered a problem while dealing with > https://issues.apache.org/jira/browse/CALCITE-6300. That is, when should > the type conversions related to map and array be performed? > > At present, I can think of two solutions. One is to convert the final > result when returning the result, such as: > https://issues.apache.org/jira/browse/CALCITE-5948, > e.g: > @LibraryOperator(libraries = {SPARK}) > public static final SqlFunction ARRAY_COMPACT = > SqlBasicFunction.create(SqlKind.ARRAY_COMPACT, > SqlLibraryOperators::arrayCompactReturnType, > OperandTypes.ARRAY); > > The second is to convert after parameter type verification, for example, > https://issues.apache.org/jira/browse/CALCITE-6300 > @LibraryOperator(libraries = {SPARK}) > public static final SqlFunction MAP_VALUES = > SqlBasicFunction.create(SqlKind.MAP_VALUES, > ReturnTypes.TO_MAP_VALUES_NULLABLE, > OperandTypes.MAP) > .withOperandTypeInference(InferTypes.MAP_SPARK_FUNCTION_TYPE); > > Perhaps these two methods are not suitable, because they are not universal > solutions. I don’t know how the database defines this type conversion > standard, but Calcite does not seem to have a clear standard for this > conversion. But I think it should be solved because many functions in Spark > need this conversion. (p.s. I have implemented the > adjustTypeForMapFunctionConstructor api, but I don't know where to put it.) > > More discussions can be viewed in jira: > https://issues.apache.org/jira/browse/CALCITE-6300 > > If there are any mistakes in my description process, please correct me. For > solutions, if others have better suggestions or other project code > examples, please put them forward. I am happy to learn. > > Sorry for asking this question so late > > Best wishes, > Cancai Cai
