How did you use the Calcite parser and validator/converter? If you use the code directly, you should config the Lex[1] correctly for the SqlParser.Config in FrameworkConfig (i.e. make the caseSensitive false).
The CalcteCatalogReader would then initialize from this FrameworkConfig and it would resolve the identifiers base on the config. If you use through the Avatica JDBC driver, config the parameters, something like this: jdbc:calcite:caseSensitive=false ... [1] https://github.com/apache/calcite/blob/69f25863f5f4197c17927a39a82cbf1cffd12b80/core/src/main/java/org/apache/calcite/config/Lex.java#L37 Best, Danny Chan 在 2020年6月16日 +0800 PM5:05，Vladimir Ozerov <ppoze...@gmail.com>，写道： > Hi colleagues, > > I am trying to implement case insensitive resolution of column/table/schema > names for our Apache Calcite integration in Hazelcast and got stuck. I hope > that the community might help me. > > Consider that we have a table source that contains the following Java class: > > class Employee { > LocalDate birthDate > } > > I would like to have an SQL engine that could resolve identifiers in > accordance with ANSI SQL standard, which basically says that unquoted > identifiers should be compared in a case-insensitive way, while quoted > identifiers should be compared in a case-sensitive way. Let's focus on > columns only for now: > > SELECT birthDate FROM employee // OK > SELECT birthdate FROM employee // OK > SELECT BIRTHDATE FROM employee // OK > SELECT `birthDate` FROM employee // OK > SELECT `birthdate` FROM employee // Fail > SELECT `BIRTHDATE` FROM employee // Fail > > That is, my source is a collection of Java objects, and the natural name of > the column is "birthDate". But I would like it to be accessible as > "birthDate", birthDate, BIRTHDate, etc. > > My problem comes from the fact that casing configuration is applied during > parsing and by the time the table is asked for a column, the information > whether the user request was quoted or not is lost. Consider that I have a > table RelDataType["birthDate"]. Now consider what happens with different > combinations of casing configuration: > 1) [unquoted=UNCHANGED, quoted=UNCHANGED]: "SELECT BIRTHDATE" doesn't work > obviously > 2) [unquoted=UPPER, quoted=UNCHANGED]: "SELECT BIRTHDATE" doesn't work > again, because parser normalizes unqouted identifier to upper case, but > RelDataType has a column "birthDate" > 3) Same as p.2, but with manual normalization of RelDataType > to RelDataType["BIRTHDATE"]: "SELECT BIRTHDATE" works now, but "SELECT > `birthDate`" don't! > > Is there any built-in solution to the above problem? > > Regards, > Vladimir.
