From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 16A4C25FF5 for ; Wed, 16 Jan 2019 15:54:22 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDkp-RmmB0EW for ; Wed, 16 Jan 2019 15:54:21 -0500 (EST) Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id C073B2525F for ; Wed, 16 Jan 2019 15:54:21 -0500 (EST) Subject: [tarantool-patches] Re: [PATCH 2/6] sql: rework ALTER TABLE grammar References: <0117c011c631182ddd64cff7a46e2b3e940bf03c.1547035183.git.korablev@tarantool.org> <65ef264c-c582-3d4d-2f5c-269c75decd98@tarantool.org> <9D3AFBAC-9E9B-4CD9-8818-4125386985D0@tarantool.org> From: Vladislav Shpilevoy Message-ID: <7d75d4df-5543-3544-565a-95b8badca1c0@tarantool.org> Date: Wed, 16 Jan 2019 23:54:11 +0300 MIME-Version: 1.0 In-Reply-To: <9D3AFBAC-9E9B-4CD9-8818-4125386985D0@tarantool.org> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: "n.pettik" , tarantool-patches@freelists.org 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: > > ::= … > > 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 > (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.