There are a few related concepts that make up the general idea of "dialect": * *dialect* determines how the JDBC adapter convert SqlNodes to SQL (e.g. generate "LIMIT 5" or "FETCH 5 ROWS") * *conformance* determines what features the validator will allow (e.g. does "GROUP BY 1" mean group by the first field or the literal 1) * *parserConfig* parameters control the parser, for example identifiers (quoted using brackets, or back-ticks or double-quotes), and how it treats the case of quoted and unquoted identifiers * *library* is a set of built-in functions. For example, you might want to use standard SQL functions plus Oracle's function set (e.g. DECODE) * *type system* determines things such as what is the maximum length of a VARCHAR value
These are intentionally kept separate in the code. We built a bridge between dialect parserConfig in https://issues.apache.org/jira/browse/CALCITE-3050. It's worth reading that issue for the back-story. To parse Teradata SQL, you probably need to create a library (for functions) and a conformance. Maybe a new constant Lex.TERADATA. Julian If you want to parse Tera On Thu, Mar 26, 2020 at 3:44 PM David Valenzuela Rodriguez <[email protected]> wrote: > > Hi! > > I'm currently evaluating the Apache Calcite framework for the purposes of > parsing Teradata SQL. As far as I can tell, this is accomplished by > defining a SqlOperatorTable with TD-specific operators. Other than that, > I'm not really sure how to integrate that SqlOperatorTable into the > Parser/Planner. Are there any guidelines or examples of this? I haven't > really seen this, but I assume this is not something new. > > Thanks in advance! > > -- > David Valenzuela > Software Engineer | Data & Discovery | GROUPON > mobile 425.614.5243 > [email protected]
