Zhiqiang He,
You are correct that CREATE TABLE is not in the SQL standard. That’s why I
propose to treat it differently than SELECT and DML. I going to make a case
AGAINST re-usable code.
For SELECT, we know that every project using Calcite’s parser will need to
extend the parser, and therefore we take pains to make the parser extensible
(by various means).
For CREATE TABLE, I would like to have the freedom to add features. We might
add features that dependent projects would not want to implement. For example,
for spatial indexes[1] I am thinking of adding derived columns and sort keys:
CREATE TABLE Restaurants (
id int,
name varchar(20),
longitude double,
latitude double,
h double derived (Hilbert(longitude, latitude)))
SORT KEY s1 (hilbert);
Other projects that use Calcite’s parser may not want derived columns and sort
keys, and we shouldn’t be arguing with those projects. I think the DDL module
(or it may turn out to be the “stateful repository” module) should go its own
way with DDL syntax, and if other projects want to use the same syntax they
should employ the oldest form of re-use: copy-paste.
We will doubtless evolve common code — in fact the planner rules for Spatial
indexes will drive from RelOptPredicateList and won’t even know about derived
columns as such because derived columns will be in the DDL module — but the DDL
parser should not be part of that common code. That will allow us to move
faster and not cause pain to other projects.
Julian
[1] https://issues.apache.org/jira/browse/CALCITE-1861
<https://issues.apache.org/jira/browse/CALCITE-1861>
> On Sep 11, 2017, at 9:09 AM, Tyler Akidau <[email protected]> wrote:
>
> +James <[email protected]>, FYI
>
> On Mon, Sep 11, 2017 at 12:07 AM Shaoxuan Wang <[email protected]> wrote:
>
>> This sounds good. If we decide to go with this plan, we should do it
>> carefully to make sure the calcite built-in DDL module is general enough
>> that different projects can easily utilize and extend it. It would be great
>> if we start this with a design proposal.
>>
>> Regards,
>> Shaoxuan
>>
>> On Sat, Sep 9, 2017 at 1:28 AM, Julian Hyde <[email protected]> wrote:
>>
>>> It’s in core/src/test/codegen/includes/parserImpls.ftl (i.e. a parser
>>> extension used in tests) but we don’t want to add it to the core parser
>>> because other projects want to have their own CREATE TABLE syntax.
>>>
>>> I have been thinking of moving DDL into a separate module, so if people
>>> want to use Calcite+DDL in production they could do so. What do people
>>> think?
>>>
>>> Julian
>>>
>>>
>>>
>>>> On Sep 8, 2017, at 7:53 AM, 王翔宇 <[email protected]> wrote:
>>>>
>>>> Looks like CREATE is not currently supported by the parser. I wanna add
>>> it.
>>>
>>>
>>
