parsing DDL

[James Taylor <ja...@apache.org>]

What's the best way to handle parsing, compiling, and validating DDL
statements? I'm hoping that Phoenix would be able to leverage the
parser of Calcite for this as well, as otherwise we'd need to maintain
our own parser and compiler. The particular time this would get
painful is in the definition of functional indexes which can contain
arbitrary expressions.

Are there extension points we could hook into?

Thanks,
James

Re: parsing DDL

[Julian Hyde <ju...@gmail.com>]

As you say, you cannot separate the DDL parser from the core SQL (SELECT and DML such as INSERT, UPDATE, DELETE, UPSERT), because as you say there are expressions in functional indexes, and of course the CREATE VIEW statement. And, via JDBC, the user is allowed to perform Statement.executeUpdate(sql) with a string that might be DML (say INSERT) or DDL.

That said, each project that uses Calcite will tend to have different DDL. We might manage to create a common core for SELECT, but not for DDL, because DDL is not standardized and is much more diverse.

I recommend that you create a combined parser for Phoenix SELECT+DML+DDL. The parser is already a freemarker template, so you can easily include extra files at various places in parser.jj. Take a look at the generate-parser maven target in core/pom.xml.

Also note that the core.jar contains parser.jj.

We would be happy to discuss adding extra “expansion points” in parser.jj if you need them.

Julian
 

On Feb 26, 2015, at 11:33 AM, James Taylor <ja...@apache.org> wrote:

> What's the best way to handle parsing, compiling, and validating DDL
> statements? I'm hoping that Phoenix would be able to leverage the
> parser of Calcite for this as well, as otherwise we'd need to maintain
> our own parser and compiler. The particular time this would get
> painful is in the definition of functional indexes which can contain
> arbitrary expressions.
> 
> Are there extension points we could hook into?
> 
> Thanks,
> James