On Wed, Feb 24, 2021 at 9:51 AM Ruben Q L <rube...@gmail.com> wrote: > Honestly, I don't know the details. I just know that on our application we > use "withIdentifierExpansion(true)", to avoid potential issues (I guess > like the one you had). > Several internal Calcite classes do the same, maybe someone with more > experience on the SqlValidator could give more info. > > > Regarding the SUBSTR issue, I was expecting that changing the > CalciteConnectionConfig as: > CalciteConnectionConfig.DEFAULT > .set(CalciteConnectionProperty.CASE_SENSITIVE, "false") > .set(CalciteConnectionProperty.FUN, "oracle") > would do the trick; but it seems it does not. > > Instead, what I think would work in your test would be leaving the > CalciteConnectionConfig as you have it, and enlarge the > SqlStdOperatorTable: instead of just > SqlStdOperatorTable.instance() > use > SqlOperatorTables.chain(SqlStdOperatorTable.instance(), > > SqlLibraryOperatorTableFactory.INSTANCE.getOperatorTable(SqlLibrary.ORACLE)) > (or whatever SqlLibrary suits your needs). Could you verify it? >
Unfortunately, the suggestion did not seem to work :( I tried a) setting the FUN property, b) just using the chained operator table and c) both of those together. I am continuing to look at various Calcite unit tests etc to see if I can spot any ideas. Meanwhile, any other suggestions are welcome. Thanks!
