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