[jira] [Commented] (CALCITE-4888) The type of generated search argument literal is wrong if the literal types of RelBuilder.in are different and compatible

["Jing Zhang (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467779#comment-17467779 ] 

Jing Zhang commented on CALCITE-4888:
-------------------------------------

Hi [~julianhyde], thanks a lot for the feedback.
> Can you fix the Jira summary? Bug summaries should NEVER start with 'Fix'. You have written some good summaries in your test case javadoc.

Done

> I don't think RelBuilder.in should be throwing a ClassCastException. IllegalArgumentException, with a predictable message, is more appropriate.

I'm sorry I didn't explain it clearly before. 
The ClassCastException would only be thrown out when simply the filter predicates. 
If without simplification, RelBuilder would generate a disjunction expression instead of throw ClassCastException if types of the ranges are not compatible. I've added the test in RelBuilderTest#testFilterInWithNotCompatibleArgumentsWithoutSimplification.
If enable simplification, there would be a ClassCastException when simplify the filter predicates in SargCollector.RexSargBuilder#addRange, I've updates the code here to throw an IllegalArgumentException with a predictable message.

Please review the pull request when you have time, thanks a lot.



> 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)