[tarantool-patches] Re: [PATCH 2/6] sql: rework ALTER TABLE grammar

[Vladislav Shpilevoy]

Thanks for the fixes! See 2 comments below.

On 16/01/2019 23:06, n.pettik wrote:
> 
>> On 09/01/2019 15:13, Nikita Pettik wrote:
>>> Since ALTER TABLE ADD CONSTRAINT can be used to add various constraint
>>> types (foreign key, unique etc), we should rework its grammar.
>>
>> 1. But you still can not add a unique constraint via ADD CONSTRAINT ...
>> The reworked grammar can be used for foreign keys only, until the last
>> commit.
> 
> Yep, and what is your objection?
> Sorry, really can’t understand.

1. You've stated that CONSTRAINT can be used for indexes, but it can not
in this commit. It *could*, and it is used further, but on this commit
it is not possible. I know, it is nit, but it slightly cuts my ear.

> 
>>> As a reference for it lets use one from ANSI.
>>> Needed for #3097
>>> ---
>>>   src/box/sql/parse.y | 44 +++++++++++++++++++++++++++++---------------
>>>   1 file changed, 29 insertions(+), 15 deletions(-)
>>> diff --git a/src/box/sql/parse.y b/src/box/sql/parse.y
>>> index f4fdf58f2..874a67a9b 100644
>>> --- a/src/box/sql/parse.y
>>> +++ b/src/box/sql/parse.y
>>> @@ -318,10 +318,8 @@ tcons ::= UNIQUE LP sortlist(X) RP.
>>>                                                      SQL_INDEX_TYPE_CONSTRAINT_UNIQUE);}
>>>   tcons ::= CHECK LP expr(E) RP onconf.
>>>                                    {sql_add_check_constraint(pParse,&E);}
>>> -tcons ::= FOREIGN KEY LP eidlist(FA) RP
>>> -          REFERENCES nm(T) eidlist_opt(TA) refargs(R) defer_subclause_opt(D). {
>>> -    sql_create_foreign_key(pParse, FA, &T, TA, D, R);
>>> -}
>>> +tcons ::= foreign_key_def.
>>
>> 2. Sorry for a nit, but I do not like _def for non-struct things. Why not
>> just foreign_key? For example, 'expr' rule is just 'expr', not 'expr_def'.
>> The same about other new _def prefixes here and in the last commit.
> 
> I took these names from ANSI grammar:
> 
> <referential constraint definition> ::= …
> 
> I can expose it to foreign_key_definition, for instance.

2. ANSI is good source of grammar, but I am not sure if it is so
good for naming. In Tarantool we use _def for structures, describing
an arising object.

> 
>>
>>> +
>>>   %type defer_subclause_opt {int}
>>>   defer_subclause_opt(A) ::= .                    {A = 0;}
>>>   defer_subclause_opt(A) ::= defer_subclause(A).
>>> @@ -1444,22 +1442,38 @@ cmd ::= ANALYZE.                {sqlite3Analyze(pParse, 0);}
>>>   cmd ::= ANALYZE nm(X).          {sqlite3Analyze(pParse, &X);}
>>>     //////////////////////// ALTER TABLE table ... ////////////////////////////////
>>> -cmd ::= ALTER TABLE fullname(X) RENAME TO nm(Z). {
>>> -  pParse->constraint->table_name = X;
>>> +cmd ::= alter_table_start alter_table_action .
>>
>> 3. The same. How about 'alter_table_action' -> 'alter_table’?
> 
> I used _action for the same reason:
> 
> <alter table statement> ::= ALTER TABLE <table name> <alter table action>
> (11.10 alter table statement)
> 
> To be honest I like this naming, so I am going to keep it as is.

I've explained my comment above and now it is up to you. I am not
rigorous about names. I understand your way of naming and it is decent.