[
https://issues.apache.org/jira/browse/CALCITE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266669#comment-14266669
]
Julian Hyde commented on CALCITE-550:
-------------------------------------
Ah, good catch. I don't think it affects this case - the default config is
REGULAR anyway - but CALCITE-489 is a hole in our testing strategy and I will
fix today.
> Case-insensitive matching of sub-query columns fails
> ----------------------------------------------------
>
> Key: CALCITE-550
> URL: https://issues.apache.org/jira/browse/CALCITE-550
> Project: Calcite
> Issue Type: Bug
> Reporter: Jinfeng Ni
> Assignee: Julian Hyde
> Fix For: 1.0.0-incubating
>
>
> Currently, the default LEX in Calcite is LEX.ORACLE, and most unit test cases
> are using LEX.ORACLE. However, when LEX is set to be MYSQL/SQL_SERVER etc,
> Calcite would complain "field/column not found error" in subquery, while the
> MYSQL/SQL_SERVER policy should allow such query.
> For example, given the following query, with LEX.MYSQL.
> {code}
> select DID
> from (select deptid as did
> FROM
> ( values (1), (2) ) as T1(deptid)
> )
> {code}
> Calcite would raise the following error:
> {code}
> Caused by: java.lang.AssertionError: Internal error: Type 'RecordType(INTEGER
> did)' has no field ‘DID'
> {code}
> According to LEX.MYSQL, the unquoted sql identifier should remain unchanged,
> and matched with case-insensitive, hence the query is valid.
> {code}
> /** Lexical policy similar to MySQL. (To be precise: MySQL on Windows;
> * MySQL on Linux uses case-sensitive matching, like the Linux file system.)
> * The case of identifiers is preserved whether or not they quoted;
> * after which, identifiers are matched case-insensitively.
> * Back-ticks allow identifiers to contain non-alphanumeric characters. */
> MYSQL(Quoting.BACK_TICK, Casing.UNCHANGED, Casing.UNCHANGED, false),
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
