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 BDE24262F9 for ; Thu, 17 Jan 2019 12:14:49 -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 Ad6_eSDeX8AC for ; Thu, 17 Jan 2019 12:14:49 -0500 (EST) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 6D7DB261A3 for ; Thu, 17 Jan 2019 12:14:49 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: [tarantool-patches] Re: [PATCH 1/6] sql: move constraint name to struct contraint_parse From: "n.pettik" In-Reply-To: <20190117105613.GC28204@chai> Date: Thu, 17 Jan 2019 20:14:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1C46D85F-B1BE-469B-9F14-87CC55C731F7@tarantool.org> References: <499ebc6e21ade22cde794f8470bf5900131d42f5.1547035183.git.korablev@tarantool.org> <834ae33b-dddd-3f51-f6f1-ef5bcc24e240@tarantool.org> <3C226FE6-A27A-46CD-8C83-AA839AAF08F2@tarantool.org> <20190117105613.GC28204@chai> 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: tarantool-patches@freelists.org Cc: Konstantin Osipov , Vladislav Shpilevoy > On 17 Jan 2019, at 13:56, Konstantin Osipov = wrote: >=20 > * n.pettik [19/01/16 23:09]: >> struct constraint_parse { >> /** Name of table which constraint belongs to. */ >> - struct SrcList *table_name; >> + struct SrcList *table; >> /** Name of the constraint currently being parsed. */ >> struct Token name; >> + /** >> + * List of columns involved in constraint definition: >> + * indexed or referencing columns. >> + */ >> + struct ExprList *cols; >=20 > Why not use constraint_def here and all future parser-specific > objects? _def is our widely used abbreviation for "definition". A > parser creates a constraint definition, and then it is used to > create a runtime constraint object - struct constraint. Do you suggest only rename this structure to constraint_def? We don=E2=80=99t have constraint_def for the reason that every = constraint is stored in its own way: unique constraints as a part of indexes; FK constraints are represented by fkey/fkey_def; check constraints are stored as raw strings in space format. And they don=E2=80=99t have = nothing in common except for name (meanwhile in most cases it is auto-generated name) and name of table they are related to. If you suggest to use *for example* fkey_def instead of fkey_parse: fkey_parse is used only within parser and contains parser specific members: list of columns as they come from parser, indication of self-referencing dependency etc. I guess we are able to fit all these things in struct fkey_def, but is it worth it? Note that fkey_parse is used ONLY during creation of FK, other manipulations depend on fkey_def/fkey from struct space. Also, see snippet in the second letter, mb it is exactly what you want.=