Hey Mark, Most SQL parsers require the reserved words to be quoted for using them as identifiers. This helps to avoid ambiguities and generally leads to simpler and more efficient parsers. I am not sure if it's possible to avoid quotes without sacrificing something else.
The standard parser also tries to remain close to the SQL standard specification and I guess that quoting rules and reserved keywords are coming from there. Most of the time we don't want to deviate a lot from the standard. Apart from the standard parser, Calcite provides the Babel parser that is more lenient and has a much smaller set of reserved keywords [1]. The Babel parser may be a better fit for your use-case. Best, Stamatis [1] https://github.com/apache/calcite/blob/3fce658c05aa88b44af8cbcfd0809a420896d62b/babel/src/main/codegen/config.fmpp#L61 On Tue, Jan 21, 2025 at 7:11 PM Mihai Budiu <[email protected]> wrote: > > There is at least one open issue related to this topic: > https://issues.apache.org/jira/browse/CALCITE-4653 > > Mihai > > ________________________________ > From: Mark Lewis <[email protected]> > Sent: Tuesday, January 21, 2025 2:32 AM > To: [email protected] <[email protected]> > Subject: Parsing SQL where a column (or table) name matches a keyword > > While trying to conversions from SQL using large volumes of existing (sample > / benchmark) SQL expressions, I have experienced significant issues due to > column (or table) names that happen to match reserved keywords. For example: > > SELECT COUNTRY FROM COUNTRY_LANGUAGE WHERE LANGUAGE = 'ENGLISH' > > Calcite appears to require quoting of any name that matches a keyword — in > this case LANGUAGE — whereas generally this isn't required since (I guess) > the meaning can be inferred from the context. > > I would be happy to try to contribute an enhancement to address this, but I > don't really know the bet place to start in the codebase; even where best to > put unit tests to drive the implementation. I am completely new to the > Calcite codebase. Can anyone provide me with some pointers on where to look > and advice on the most suitable implementation approach? >
