From: Konstantin Osipov <kostja@tarantool.org> To: tarantool-patches@freelists.org Cc: v.shpilevoy@tarantool.org, Nikita Pettik <korablev@tarantool.org> Subject: [tarantool-patches] Re: [PATCH 2/6] sql: rework ALTER TABLE grammar Date: Thu, 17 Jan 2019 14:51:00 +0300 [thread overview] Message-ID: <20190117115100.GM28204@chai> (raw) In-Reply-To: <0117c011c631182ddd64cff7a46e2b3e940bf03c.1547035183.git.korablev@tarantool.org> * Nikita Pettik <korablev@tarantool.org> [19/01/09 15:17]: > +alter_table_start ::= ALTER TABLE fullname(Z) . { > + pParse->constraint->table_name = Z; > + pParse->constraint->name.n = 0; > +} It's bikeshed at this point, but in future you will have other ALTER TABLE clauses: add/drop column, add/drop index, add/drop constraint. It's unclear why you initialize a specific parsing context (constraint definition) right in alter_table_start rule. OK for now. > + > +alter_table_action ::= add_constraint_def. > +alter_table_action ::= drop_constraint_def. Why use the same data structure for create and drop? When I drop a constraint I specify its name and (perhaps) table name, none of other properties. To capture drop context one could use: struct drop_object_def { enum object_type object_type; const char *object_name; const char *parent_object_name; }; rename of an object could be captured in a similar data structure. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov
next prev parent reply other threads:[~2019-01-17 11:51 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-09 12:13 [tarantool-patches] [PATCH 0/6] Introduce ALTER TABLE ADD CONSTRAINT UNIQUE/PK Nikita Pettik 2019-01-09 12:13 ` [tarantool-patches] [PATCH 1/6] sql: move constraint name to struct contraint_parse Nikita Pettik 2019-01-14 14:04 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 20:06 ` n.pettik 2019-01-16 20:54 ` Vladislav Shpilevoy 2019-01-17 10:56 ` Konstantin Osipov 2019-01-17 17:14 ` n.pettik 2019-01-09 12:13 ` [tarantool-patches] [PATCH 2/6] sql: rework ALTER TABLE grammar Nikita Pettik 2019-01-14 14:05 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 20:06 ` n.pettik 2019-01-16 20:54 ` Vladislav Shpilevoy 2019-01-17 11:51 ` Konstantin Osipov [this message] 2019-01-17 17:14 ` n.pettik 2019-01-18 1:42 ` Konstantin Osipov 2019-01-09 12:13 ` [tarantool-patches] [PATCH 3/6] sql: remove start token from sql_create_index args Nikita Pettik 2019-01-09 12:13 ` [tarantool-patches] [PATCH 4/6] sql: refactor getNewIid() function Nikita Pettik 2019-01-14 14:05 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-09 12:13 ` [tarantool-patches] [PATCH 5/6] sql: fix error message for improperly created index Nikita Pettik 2019-01-14 14:06 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 20:06 ` n.pettik 2019-01-09 12:13 ` [tarantool-patches] [PATCH 6/6] sql: introduce ALTER TABLE ADD CONSTRAINT UNIQUE/PRIMARY KEY Nikita Pettik 2019-01-14 14:06 ` [tarantool-patches] " Vladislav Shpilevoy 2019-01-16 20:06 ` n.pettik 2019-01-16 20:54 ` Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190117115100.GM28204@chai \ --to=kostja@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH 2/6] sql: rework ALTER TABLE grammar' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox