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 162E2252FC for ; Thu, 24 Jan 2019 03:31: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 YcHRyNVjkp7Y for ; Thu, 24 Jan 2019 03:31:21 -0500 (EST) Received: from smtp10.mail.ru (smtp10.mail.ru [94.100.181.92]) (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 53EF1252D1 for ; Thu, 24 Jan 2019 03:31:21 -0500 (EST) Date: Thu, 24 Jan 2019 11:31:19 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH v2 5/5] sql: introduce ALTER TABLE ADD CONSTRAINT UNIQUE/PRIMARY KEY Message-ID: <20190124083119.GB3573@chai> References: <6dacbf399fb84152368b47576b42b4bc3da23e78.1548265148.git.korablev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6dacbf399fb84152368b47576b42b4bc3da23e78.1548265148.git.korablev@tarantool.org> 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: Nikita Pettik Cc: tarantool-patches@freelists.org, v.shpilevoy@tarantool.org * Nikita Pettik [19/01/23 23:01]: > Table (aka space) can be created without indexes at least from Lua-land > (note that according ANSI SQL table may lack PK). Since there were no > facilities to create primary key constraint on already existing table, > lets extend ADD CONSTRAINT statement with UNIQUE and PRIMARY KEY > clauses. In this case, UNIQUE works exactly in the same way as CREATE > UNIQUE INDEX ... statement does. In Tarantool primary index is an index > with id == 0, so during execution of ADD CONSTRAINT PRIMARY KEY we check > that there is no any entries in _index space and create that one. > Otherwise, error is raised. > > Part of #3097 > Follow-up #3914 > > +static void > +pk_check_existence(struct Parse *parse, uint32_t space_id, int _index_cursor) I think the name is confusing. You can't check if an index exists at code generation phase. Things may change between code generation and execution. So you actually generate code for checking if an index exists. This is why every function must have a comment. Even a static one. A comment is a checksum that the function does what the writer meant it to do. > +{ > + struct Vdbe *v = sqlite3GetVdbe(parse); > + int tmp_reg = ++parse->nMem; > + sqlite3VdbeAddOp2(v, OP_Integer, space_id, tmp_reg); > + int found_addr = sqlite3VdbeAddOp4Int(v, OP_NotFound, _index_cursor, 0, > + tmp_reg, 1); > + sqlite3VdbeAddOp4(v, OP_Halt, SQLITE_ERROR, ON_CONFLICT_ACTION_FAIL, 0, > + "multiple primary keys are not allowed", P4_STATIC); > + sqlite3VdbeJumpHere(v, found_addr); > +} -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov