Mihai Budiu created CALCITE-5813:
------------------------------------
Summary: Type inference for REPEAT sql function is incorrect
Key: CALCITE-5813
URL: https://issues.apache.org/jira/browse/CALCITE-5813
Project: Calcite
Issue Type: Bug
Reporter: Mihai Budiu
The result of the following SQL query (enabling the proper dialects for the
REPEAT function):
{code:sql}
SELECT REPEAT('abc', 2)
{code}
is incorrectly computed by Calcite as 'abc' (no repetitions) if the constant
folding optimization PROJECT_REDUCE_EXPRESSIONS is enabled.
(I am not sure exactly how to modify the operator tables of the RelOptFixture,
so I had to jump through some hoops to create a simple reproduction.)
The plans before and after are as following:
{code:java}
LogicalProject(EXPR$0=[REPEAT('abc', 2)])
LogicalValues(tuples=[[{ 0 }]])
---------------
LogicalProject(EXPR$0=['abc':VARCHAR(3)])
LogicalValues(tuples=[[{ 0 }]])
{code}
The root cause is the following:
In the definition of the REPEAT SqlFunction:
{code:java}
@LibraryOperator(libraries = {BIG_QUERY, MYSQL, POSTGRESQL})
public static final SqlFunction REPEAT =
SqlBasicFunction.create("REPEAT",
ReturnTypes.ARG0_NULLABLE_VARYING, /// <<< WRONG
OperandTypes.STRING_INTEGER,
SqlFunctionCategory.STRING);
{code}
the output type is the same as the first argument type. If the first argument
type is VARCHAR(N), the output type is also VARCHAR(N). This causes the
optimizer to first correctly compute the repeated string and then truncate
result to the original length.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
