[
https://issues.apache.org/jira/browse/CALCITE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245847#comment-14245847
]
Julian Hyde commented on CALCITE-528:
-------------------------------------
Has the validator decided that "column1" and "Column1" are the same field? If
so, they should end up being the same field after sql-to-rel translation. It
does not matter whether that field is called "column1" or "Column1" or
"foobar$56" -- it's just for debugging purposes and you shouldn't be relying on
it being anything in particular. Calcite happens to use case-sensitive matching
for RelNode field names but it should not matter, because users can't see
RelNode fields.
The case-sensitivity flags only apply to SQL parsing/validation. It sounds like
there is either a bug in sql-to-rel conversion or no bug at all.
> Creating output row type of a Join does not obey case-sensitivity flags
> -----------------------------------------------------------------------
>
> Key: CALCITE-528
> URL: https://issues.apache.org/jira/browse/CALCITE-528
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 0.9.1-incubating
> Reporter: Aman Sinha
> Assignee: Julian Hyde
>
> In JoinRelBase.createJoinType() which creates a row type of the output row, a
> HashSet of String is used to keep track of unique field names. The field
> names 'column1' and 'Column1' will both be stored. This creates a problem
> for systems which are treating identifiers as case-insensitive (such as
> Drill) which rely on a Project below a Join to create unique names if the
> join columns are the same name (regardless of case).
> Ideally, the comparison for this should be done based on the criteria
> specified in the Lex settings when instantiating the
> SqlParser.ParserConfigImpl. So, if the parser was created with MYSQL Lex
> settings (see Lex.java), it should be obeyed by the
> JoinRelBase.createJoinType().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
