From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Roman Khabibov <roman.habibov@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2 3/3] sql: support constraint drop Date: Sat, 29 Feb 2020 16:32:01 +0100 [thread overview] Message-ID: <980e9649-2e7c-424c-7d75-1945cb24d587@tarantool.org> (raw) In-Reply-To: <1509E852-025B-4147-9DFE-FA4202C5C3A0@tarantool.org> Thanks for the patch! >>> diff --git a/src/box/sql/build.c b/src/box/sql/build.c >>> index d9bf8de91..76ad79350 100644 >>> --- a/src/box/sql/build.c >>> +++ b/src/box/sql/build.c >>> @@ -2052,35 +2052,78 @@ fk_constraint_change_defer_mode(struct Parse *parse_context, bool is_deferred) >>> is_deferred; >>> } >>> >>> +/** >>> + * Emit code to drop the entry from _index or _ck_contstraint or >>> + * _fk_constraint space corresponding with the constraint type. >>> + */ >>> void >>> -sql_drop_foreign_key(struct Parse *parse_context) >>> +sql_drop_constraint(struct Parse *parse_context) >>> { >>> - struct drop_entity_def *drop_def = &parse_context->drop_fk_def.base; >>> - assert(drop_def->base.entity_type == ENTITY_TYPE_FK); >>> + struct drop_entity_def *drop_def = >>> + &parse_context->drop_constraint_def.base; >>> + assert(drop_def->base.entity_type == ENTITY_TYPE_CONSTRAINT); >>> assert(drop_def->base.alter_action == ALTER_ACTION_DROP); >>> const char *table_name = drop_def->base.entity_name->a[0].zName; >>> assert(table_name != NULL); >>> - struct space *child = space_by_name(table_name); >>> - if (child == NULL) { >>> + struct space *space = space_by_name(table_name); >>> + if (space == NULL) { >>> diag_set(ClientError, ER_NO_SUCH_SPACE, table_name); >>> parse_context->is_aborted = true; >>> return; >>> } >>> - char *constraint_name = >>> - sql_name_from_token(parse_context->db, &drop_def->name); >>> - if (constraint_name == NULL) { >>> + char *name = sql_name_from_token(parse_context->db, &drop_def->name); >>> + if (name == NULL) { >>> + parse_context->is_aborted = true; >>> + return; >>> + } >>> + struct constraint_id *id = space_find_constraint_id(space, name); >>> + if (id == NULL) { >> >> 2. We perhaps need to do that at runtime - search in fk, ck, and index >> spaces, or somehow in this hash table. Because otherwise we rely on >> having struct space object, which in theory won't always be the case. >> which in theory won't always be the case. > Why? Can you, please, explain? Remote client nodes do not have any schema objects. If a request requires struct space *, it can't be compiled on the client. And this is where we are going to. >> However, not in scope of this patch maybe. Because anyway we have >> struct space used in lots of other places. And I don't know a general >> solution how to get rid of all of them. Yet. > Do you mean to avoid struct space usage within build.c? Yes, I want us to avoid any schema objects usage where possible. > diff --git a/src/box/sql/build.c b/src/box/sql/build.c > index 00877b7d8..17fd07f78 100644 > --- a/src/box/sql/build.c > +++ b/src/box/sql/build.c > @@ -1519,7 +1517,8 @@ vdbe_emit_fk_constraint_drop(struct Parse *parse_context, char *constraint_name, constraint_name can become 'const' now. > struct Vdbe *vdbe = sqlGetVdbe(parse_context); > assert(vdbe != NULL); > int key_reg = sqlGetTempRange(parse_context, 3); > - sqlVdbeAddOp4(vdbe, OP_String8, 0, key_reg, 0, constraint_name, > + const char *name_copy = sqlDbStrDup(parse_context->db, constraint_name); > + sqlVdbeAddOp4(vdbe, OP_String8, 0, key_reg, 0, name_copy, > P4_DYNAMIC); > sqlVdbeAddOp2(vdbe, OP_Integer, child_def->id, key_reg + 1); > const char *error_msg =
next prev parent reply other threads:[~2020-02-29 15:32 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-09 10:15 [Tarantool-patches] [PATCH] " Roman Khabibov 2020-01-13 17:00 ` Nikita Pettik 2020-01-24 14:21 ` [Tarantool-patches] [PATCH 2/2] " Roman Khabibov 2020-01-28 17:39 ` Nikita Pettik 2020-02-01 17:36 ` Roman Khabibov 2020-02-11 16:56 ` Nikita Pettik 2020-02-16 10:24 ` Roman Khabibov 2020-02-20 19:55 ` Nikita Pettik 2020-02-20 23:09 ` [Tarantool-patches] [PATCH] " Vladislav Shpilevoy 2020-02-20 23:36 ` Nikita Pettik 2020-02-29 12:47 ` [Tarantool-patches] [PATCH v2 3/3] " Roman Khabibov 2020-02-29 15:32 ` Vladislav Shpilevoy [this message] 2020-03-03 10:13 ` Roman Khabibov 2020-03-03 10:12 [Tarantool-patches] [PATCH v2 0/3] Add ability to drop constraints Roman Khabibov 2020-03-03 10:12 ` [Tarantool-patches] [PATCH v2 3/3] sql: support constraint drop Roman Khabibov
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=980e9649-2e7c-424c-7d75-1945cb24d587@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=roman.habibov@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 3/3] sql: support constraint drop' \ /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