Igor, When you are saying that we should not allow the dialect changing, are you referring to changes in runtime when a node is already up-and-running? Generally, it will be more than enough if a dialect can be set statically and globally -- the user selects the dialect for the entire cluster via a configuration parameter and starts the nodes after that.
- Denis On Fri, Dec 27, 2019 at 7:05 AM Seliverstov Igor <gvvinbl...@gmail.com> wrote: > Denis, > > > Is it true that Calcite can parse MySQL, Oracle > > Yes, it can. > > > Do I need to select a dialect globally or can it be set on a per-query > > level? > > Technically a parser, a validator, a planner, other components are created > and configured for each query call (because they are stateful). So you may > configure it per query, or hardcode a desired dialect, or get it from > configuration - it’s up to you, but we expect parser configuration to be > (more or less) static, it is a part of initial framework configuration. I > think we should not allow such parameters (as a dialect) changing. > > Regards, > Igor > > > 27 дек. 2019 г., в 07:47, Denis Magda <dma...@apache.org> написал(а): > > > > Igor S., Roman and others who involved in Calcite prototyping, > > > > Is it true that Calcite can parse MySQL, Oracle, ANSI-99 and other > dialects > > as suggested by this page? > > > https://calcite.apache.org/apidocs/org/apache/calcite/sql/validate/SqlConformanceEnum.html > > > > Do I need to select a dialect globally or can it be set on a per-query > > level? > > > > - > > Denis > >
