From: Roman Khabibov <roman.habibov@tarantool.org> To: Nikita Pettik <korablev@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v4 2/5] sql: refactor create_table_def and parse Date: Tue, 10 Nov 2020 15:17:55 +0300 [thread overview] Message-ID: <28F38887-3AED-4D94-9019-1BBDCF176AEF@tarantool.org> (raw) In-Reply-To: <20201105221728.GA8188@tarantool.org> Hi! Thanks for the review. > On Nov 6, 2020, at 01:17, Nikita Pettik <korablev@tarantool.org> wrote: > > On 09 Oct 16:45, Roman Khabibov wrote: >> Move ck, fk constraint lists from struct create_table_def into new >> defs and autoincrement into struct Parse to make the code more >> reusable when implementing <ALTER TABLE ADD COLUMN>. >> >> Needed for #3075 >> --- >> >> +/** >> + * Emit code to create sequences, indexes, check and foreign key >> + * constraints appeared in <CREATE TABLE>. >> + */ >> +static void >> +vdbe_emit_create_constraints(struct Parse *parse, int reg_space_id) > > I'd move this refactoring in a separate patch. Up to you. > >> @@ -3306,15 +3324,15 @@ vdbe_emit_halt_with_presence_test(struct Parse *parser, int space_id, >> int >> sql_add_autoincrement(struct Parse *parse_context, uint32_t fieldno) >> { >> - if (parse_context->create_table_def.has_autoinc) { >> + if (parse_context->has_autoinc) { >> diag_set(ClientError, ER_SQL_SYNTAX_WITH_POS, >> parse_context->line_count, parse_context->line_pos, >> "table must feature at most one AUTOINCREMENT field"); >> parse_context->is_aborted = true; >> return -1; >> } >> - parse_context->create_table_def.has_autoinc = true; >> - parse_context->create_table_def.autoinc_fieldno = fieldno; >> + parse_context->has_autoinc = true; >> + parse_context->autoinc_fieldno = fieldno; >> return 0; >> } >> >> diff --git a/src/box/sql/parse_def.h b/src/box/sql/parse_def.h >> index cb0ecd2fc..21829b6f0 100644 >> --- a/src/box/sql/parse_def.h >> +++ b/src/box/sql/parse_def.h >> @@ -205,26 +205,20 @@ struct create_entity_def { >> struct create_table_def { >> struct create_entity_def base; >> struct space *new_space; >> - /** >> - * Number of FK constraints declared within >> - * CREATE TABLE statement. >> - */ >> - uint32_t fkey_count; >> - /** >> - * Foreign key constraint appeared in CREATE TABLE stmt. >> - */ >> - struct rlist new_fkey; >> - /** >> - * Number of CK constraints declared within >> - * CREATE TABLE statement. >> - */ >> - uint32_t check_count; >> - /** Check constraint appeared in CREATE TABLE stmt. */ >> - struct rlist new_check; >> - /** True, if table to be created has AUTOINCREMENT PK. */ >> - bool has_autoinc; >> - /** Id of field with AUTOINCREMENT. */ >> - uint32_t autoinc_fieldno; > > Did you consider adding create_column_def class? Imho it would > fit better in parse hierarchy: it would derive from create_entity_def, > has field_def, autoinc, ck, fk members. Yes. We discussed this a lot with Vlad. This class is implemented in the main, last patch of the patchset. Unfortunately, the check and fk constraints lists had to be removed separately from this class, because the check and fk descriptions can occur separately from the column descriptions in CREATE TABLE, e.g. " CREATE TABLE t (a INT PRIMARY KEY, CHECK (a > 0))”. To make the code reusable, it is easier to emit opcode for all constants after CREATE TABLE parsing. For the same reason, autoinc is separate. >> +}; >> + >> +struct create_checks_def { > > Why not create_ck_constraint_def? This naming would be more consistent > with existing ck_contraint_def etc. The same for create_fk_constraint_def. Because these are lists of constant defs. We decided to emphasize this. > >> + /** List of ck_constraint_parse objects. */ >> + struct rlist checks; >> + /** Count of ck_constraint_parse objects. */ >> + uint32_t count; >> +}; >> +
next prev parent reply other threads:[~2020-11-10 12:17 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-09 13:45 [Tarantool-patches] [PATCH v4 0/5] Support column addition Roman Khabibov 2020-10-09 13:45 ` [Tarantool-patches] [PATCH v4 1/5] sql: rename TK_COLUMN to TK_COLUMN_REF Roman Khabibov 2020-11-05 22:17 ` Nikita Pettik 2020-10-09 13:45 ` [Tarantool-patches] [PATCH v4 2/5] sql: refactor create_table_def and parse Roman Khabibov 2020-11-05 22:17 ` Nikita Pettik 2020-11-10 12:17 ` Roman Khabibov [this message] 2020-11-17 20:23 ` Nikita Pettik 2020-11-15 11:51 ` roman 2020-10-09 13:45 ` [Tarantool-patches] [PATCH v4 3/5] schema: add box_space_field_MAX Roman Khabibov 2020-11-05 22:18 ` Nikita Pettik 2020-10-09 13:45 ` [Tarantool-patches] [PATCH v4 4/5] sql: use parser's region of "index" array Roman Khabibov 2020-11-05 22:26 ` Nikita Pettik 2020-11-10 12:18 ` Roman Khabibov 2020-11-17 20:35 ` Nikita Pettik [not found] ` <20201009134529.13212-6-roman.habibov@tarantool.org> 2020-11-06 15:57 ` [Tarantool-patches] [PATCH v4 5/5] sql: support column addition Nikita Pettik 2020-11-10 12:18 ` Roman Khabibov 2020-11-18 16:15 ` Nikita Pettik 2020-11-15 11:51 ` roman
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=28F38887-3AED-4D94-9019-1BBDCF176AEF@tarantool.org \ --to=roman.habibov@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v4 2/5] sql: refactor create_table_def and parse' \ /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