[
https://issues.apache.org/jira/browse/CALCITE-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jing Zhang updated CALCITE-4888:
--------------------------------
Description:
The type of resulted search argument literal is wrong if the literal types of
RelBuilder.in are different and compatible with each other.
For example,
{code:java}
/**
* Custom type system that converts different length of CHAR type to VARCHAR
type.
*/
public static class VaryingTypeSystem extends RelDataTypeSystemImpl {
public static final RelDataTypeSystem INSTANCE = new VaryingTypeSystem();
@Override public boolean shouldConvertRaggedUnionTypesToVarying() {
return true;
}
}
RelBuilder relBuilder =
RelBuilder.create(config().typeSystem(VaryingTypeSystem.INSTANCE).build());
relBuilder.scan("EMP");
RexNode condition = relBuilder.in(relBuilder.field("JOB"),
relBuilder.literal("CLERK"), relBuilder.literal("A"));
{code}
In the above example, we overwrite the shouldConvertRaggedUnionTypesToVarying
to suggest the least restrictive type of a number of CHAR types of different
lengths should be a VARCHAR type.
We expect the type of the generated SARGS literal to be VACHAR(5).
Actually, the type of generated SARGS literal is CHAR(5) and the literal with
value 'A' is converted to char(5), which leads to wrong result data.
was:
The type of resulted search argument literal is wrong if the literal types of
RelBuilder.in are different and compatible with each other.
For example,
if call `RelBuilder.in` to create an `IN` predicate with a list of varchar
literals which have different length, generated `RexNode` are expected.
for example, ranges are `b.literal("CLERK")` and `b.literal("A")`
Generated `RexNode` seems to be unexpected because it would cast 'A' to char(5).
> The type of generated search argument literal is wrong if the literal types
> of RelBuilder.in are different and compatible
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-4888
> URL: https://issues.apache.org/jira/browse/CALCITE-4888
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Jing Zhang
> Priority: Major
> Labels: pull-request-available
> Attachments: image-2021-11-23-10-31-05-137.png, screenshot-1.png,
> screenshot-2.png, screenshot-3.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The type of resulted search argument literal is wrong if the literal types of
> RelBuilder.in are different and compatible with each other.
> For example,
> {code:java}
> /**
> * Custom type system that converts different length of CHAR type to
> VARCHAR type.
> */
> public static class VaryingTypeSystem extends RelDataTypeSystemImpl {
> public static final RelDataTypeSystem INSTANCE = new VaryingTypeSystem();
> @Override public boolean shouldConvertRaggedUnionTypesToVarying() {
> return true;
> }
> }
> RelBuilder relBuilder =
> RelBuilder.create(config().typeSystem(VaryingTypeSystem.INSTANCE).build());
> relBuilder.scan("EMP");
> RexNode condition = relBuilder.in(relBuilder.field("JOB"),
> relBuilder.literal("CLERK"), relBuilder.literal("A"));
> {code}
> In the above example, we overwrite the shouldConvertRaggedUnionTypesToVarying
> to suggest the least restrictive type of a number of CHAR types of different
> lengths should be a VARCHAR type.
> We expect the type of the generated SARGS literal to be VACHAR(5).
> Actually, the type of generated SARGS literal is CHAR(5) and the literal with
> value 'A' is converted to char(5), which leads to wrong result data.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
