[ https://issues.apache.org/jira/browse/CALCITE-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18023952#comment-18023952 ]
Mihai Budiu commented on CALCITE-7210: -------------------------------------- The root cause seems to be an incorrect type inference for LEAST/GREATEST. Calcite generally expands LEAST into a CASE, but the type inferred for the same expression using LEAST or its CASE expansion is different. > BINARY literal values may not match their type > ---------------------------------------------- > > Key: CALCITE-7210 > URL: https://issues.apache.org/jira/browse/CALCITE-7210 > Project: Calcite > Issue Type: Bug > Components: core > Affects Versions: 1.40.0 > Reporter: Mihai Budiu > Assignee: Mihai Budiu > Priority: Minor > > The following SqlOperatorTest fails: > {code:java} > final SqlOperatorFixture f = fixture() > .setFor(SqlLibraryOperators.LEAST, VmName.EXPAND) > .withLibrary(SqlLibrary.BIG_QUERY); > f.checkScalar("least(x'01', x'0202')", "0100", "BINARY(2) NOT NULL"); > {code} > The error is: > Expected: is "0100" > but: was "01" > However, the type of the result BINARY(2) is correct. But "01" is not a legal > value for this type. > This occurs because BINARY literal values do not always match their declared > type. I think there are several paths in simplification code which can lead > to this outcome. -- This message was sent by Atlassian Jira (v8.20.10#820010)