Front-end support for LIMIT ROWS DELETE statements

The first commit you have already seen here on GitHub.  The second completes the ticket by doing error checking, planning the statement, and logging the explained plan:
* The HSQL parser stores the text of the DELETE statement in the VoltXML that it generates
* `DDLCompiler` generates VoltXML from the text of the DELETE statement to verify that the statement is a DELETE that targets the correct table
  * The statement is then saved in the catalog as a child of the Table 
* After `VoltCompiler` compiles stored procedures, it proceeds to compile any DELETE statements designed to help enforce the ROW LIMIT constraint
  * It's at this time that the explained plan is logged.
OK. waiting for the partitioning to be reflected seems worth the extra
effort, just to avoid any confusion from the planner running too early.

Parsing simple DELETE statements twice is probably not going to hurt that
much -- it's probably not worth the extra coding effort of building the map
-- though I'm curious why would it be owned by the VoltCompiler and not
local to the DDLCompiler?.
If it turns out that we don't want to reiterate over all the tables to find
the statements requiring plans, maybe we'll end up building a list/set and
if we're going that far, it might as well be a map and MAYBE? that tips the
balance towards doing the StatementCompiler/QueryPlanner refactoring?

BTW, have we given any thought to the impact on trad db?

For one thing, I don't know if this change applies to an ALTER TABLE that
adds/drops a ROW LIMIT EXECUTE clause.
There probably need to be ad hoc ddl test cases for this -- I don't know if
we anticipated that in any of these tickets.

*Paul Martel*, Software Engineer
*VoltDB, Inc.*
*E: *pmartel@voltdb.com
*voltdb.com* <http://www.voltdb.com/>
Follow VoltDB [image: twitter] <https://twitter.com/VoltDB> [image:
facebook] <https://www.facebook.com/VoltDB> [image: linkedin]
<https://www.linkedin.com/company/voltdb>

On Wed, Nov 12, 2014 at 1:32 PM, Christopher M. Wolff <
notifications@github.com> wrote:

> In src/frontend/org/voltdb/compiler/VoltCompiler.java:
>
> > @@ -1133,6 +1134,39 @@ private void compileDatabase(
> >          // generated DDL
> >          m_importLines = voltDdlTracker.m_importLines.toArray(new String[0]);
> >          addExtraClasses(jarOutput);
> > +
> > +        compileRowLimitDeleteStmts(db, hsql);
>
> If you look near the beginning of this method, the call to
> ddlcompiler.compileToCatalog(db) is what actually (eventually) validates
> the DELETE statement (producing the XML that gets thrown away). The ROW
> LIMIT number is also validated here, so it seems right to validate them
> together, and it also seems like a good place in general to put validation
> that we can't do in HSQL.
>
> This is followed by a loop that updates the catalog with partitioning info
> for each table. A comment indicates that this must be done before compiling
> procedures. (Perhaps in our case it *might* be okay to compile the DELETE
> statement before this since we are forcing single-partition execution, but
> it would seem to be bad form--I like that we populate the catalog as much
> as possible *first*, and then proceed to do statement planning.)
>
> So, I'd rather not try to compile the DELETE statement as we're populating
> the catalog with tables in DDLCompiler. After some thought, it would be
> feasible to avoid the redundant parsing:
>
>    - Validate the XML for the DELETE statement, and store the XML in a
>    map owned by VoltCompiler
>    - Re-factor StatementCompiler and its callee, QueryPlanner to accept
>    XML directly
>
> Alternatively, we could use regular expressions to validate the DELETE
> statement, and not parse it at all in DDLCompiler. I'm pretty soured on
> regular expressions after seeing sqlcmd though.
>
> In the big picture, how horrible is it to parse the DELETE twice? I don't
> think it's that bad, but maybe I'm just being "overly expedient."
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/VoltDB/voltdb/pull/1790/files#r20239137>.
>