The ANTLR grammars are full of keywords that are explicitly specified everywhere they can be valid. This results in huge grammars and DFAs, and makes the IR construction way more complicated than it needs to be.
We need a general lookup mechanism for keywords using a Common -> TSQL, Common ->Snowflake, etc. We could also later adorn the table with human readable forms of the keywords and text to use in error messages, but the initial requirement is to validate things like options. The function builder code is a more complex, but similar process.
which means that the AST builders have to jump through hoops to find out what option is what, or label each alt (which generates extra contexts and memory copies for every alt).
override def visitXmlIndexOption(ctx...) ... {
if (ctx.PAD_INDEX() != NULL {}
if (ctx.FILLFACTOR() != NULL) {}
Proposed Solution
At it's simplest, we have a table something like this:
Keywords for options are now handled with a parsing rule that allows the visitor to look for options of certain kinds, such as boolean, string, and so on.
Is there an existing issue for this?
Category of feature request
Transpile
Problem statement
The ANTLR grammars are full of keywords that are explicitly specified everywhere they can be valid. This results in huge grammars and DFAs, and makes the IR construction way more complicated than it needs to be.
We need a general lookup mechanism for keywords using a Common -> TSQL, Common ->Snowflake, etc. We could also later adorn the
table
with human readable forms of the keywords and text to use in error messages, but the initial requirement is to validate things like options. The function builder code is a more complex, but similar process.We currently have many rules that look like this:
which means that the AST builders have to jump through hoops to find out what option is what, or label each alt (which generates extra contexts and memory copies for every alt).
Proposed Solution
At it's simplest, we have a
table
something like this:Though it could also hold its IR definition or anything else that proves useful.
There would be a base/common set of keywords, then a TSQL that inherited from common and a Snowflake that inherited from common. And so on.
This would at least reduce option sets to:
But we can probably merge all options into:
Though note that there are some randomly construed options that we can still specify in patterns but are not always as straight forward as
X = Y
.Our Scala code then has logic roughly like this:
Additional Context
No response