You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Vladimir Sitnikov (JIRA)" <ji...@apache.org> on 2015/01/06 12:51:34 UTC

[jira] [Commented] (CALCITE-550) Case-insensitive matching of sub-query columns fails

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

Vladimir Sitnikov commented on CALCITE-550:
-------------------------------------------

[~julianhyde],
Do you know
{code:java}
+    CalciteAssert.that()
+        .with(CalciteAssert.Config.REGULAR)
+        .with(ImmutableMap.of("lex", "SQL_SERVER"))
{code}
is not performing as one might read it?
See relevant CALCITE-489.

The second {{with(ImmutableMap}} call creates brand-new assert object and the {{.with(CalciteAssert.Config.REGULAR)}} part is _not_ used.

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