For create/drop view, show tables, use schema, etc, you can grab all the code from Drill:
grammar: https://github.com/apache/drill/blob/master/exec/java-exec/src/main/codegen/includes/parserImpls.ftl sqlcalls: https://github.com/apache/drill/tree/master/exec/java-exec/src/main/java/org/apache/drill/exec/planner/sql/parser On Thu, Apr 30, 2015 at 10:21 AM, Julian Hyde <[email protected]> wrote: > OK, great. Can you drive this by submitting pull requests. > > > On Apr 30, 2015, at 12:54 AM, Xavier Leong <[email protected]> > wrote: > > > > Thanks Julian for the insight of Calcite path. My colleague just opened > JIRA for supporting DML (705) and DDL (706). > > > > We can work together to accomplish the common goal, thanks. > > > > +1 for DML support, as it will solve the gaps in statement execute() > call differentiating a DQL preparedStatement vs a DML preparedStatement. > > > > > > -----Original Message----- > > From: Julian Hyde [mailto:[email protected]] > > Sent: Thursday, April 30, 2015 1:23 AM > > To: dev@calcite > > Subject: Re: Calcite supporting DDL > > > > I would like Calcite to support simple DDL. > > > > DDL (and other commands such as KILL STATEMENT) make it possible to do a > wide range of operations over a REST or JDBC interface. We can't expect > everything do be done locally, using Java method calls. > > > > I expect that projects that use Calcite will define their own DDL. (In > fact Drill and Phoenix already do; see > > https://issues.apache.org/jira/browse/PHOENIX-1706.) Those projects are > very likely to have their own variations on CREATE TABLE etc. so they will > want to extend the parser. What I did in Phoenix (which was in turn adapted > from Drill) is a model that other projects can follow. > > > > But the base Calcite project should have CREATE TABLE, DROP TABLE, > CREATE SCHEMA, DROP SCHEMA, CREATE [ OR REPLACE ] VIEW etc. There will be > an AST (extending SqlNode) for each of these commands, and a > command-handler. Each project that uses Calcite could extend those ASTs, > but it would be fine if it built its own AST and command-handler. > > > > On Wed, Apr 29, 2015 at 1:11 AM, Xavier Leong <[email protected]> > wrote: > >> Dear commiters, as the root schema can be immutable and change during > run time, it is possible to have DDL to change the schema, create tables, > view, or alter tables. Like to know if this part of the roadmap to support > DDL, or is it up to the storage layer (adapter) to handles schema changes > via other SPI. > >> > >> Thanks. > >> > >> DISCLAIMER > >> ========== > >> This e-mail may contain privileged and confidential information which > is the property of Persistent Systems Ltd. It is intended only for the use > of the individual or entity to which it is addressed. If you are not the > intended recipient, you are not authorized to read, retain, copy, print, > distribute or use this message. If you have received this communication in > error, please notify the sender and delete all copies of this message. > Persistent Systems Ltd. does not accept any liability for virus infected > mails. > >> > > > > DISCLAIMER > > ========== > > This e-mail may contain privileged and confidential information which is > the property of Persistent Systems Ltd. It is intended only for the use of > the individual or entity to which it is addressed. If you are not the > intended recipient, you are not authorized to read, retain, copy, print, > distribute or use this message. If you have received this communication in > error, please notify the sender and delete all copies of this message. > Persistent Systems Ltd. does not accept any liability for virus infected > mails. > > > >
