Tarantool development patches archive
 help / color / mirror / Atom feed
From: Nikita Pettik <korablev@tarantool.org>
To: Roman Khabibov <roman.habibov@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, 17 Nov 2020 20:23:18 +0000	[thread overview]
Message-ID: <20201117202318.GA19460@tarantool.org> (raw)
In-Reply-To: <28F38887-3AED-4D94-9019-1BBDCF176AEF@tarantool.org>

On 10 Nov 15:17, Roman Khabibov wrote:
> 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:
> >> +++ b/src/box/sql/parse_def.h
> >> @@ -205,26 +205,20 @@ struct create_entity_def {
> >> -	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

What does 'constant' mean? IMHO it is not so 'reusable': anyway you
have a lot of if (is_alter/is_alter_add_constr..) branches. But OK,
since patch is ready, I believe this refactoring is not worth time
required for that.

> 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.

Do not get what's that supposed to mean. This is naming which is taken in
our source code.. If you have any strong arguments from your discussion,
please copy-paste them in the answer.

  reply	other threads:[~2020-11-17 20:23 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
2020-11-17 20:23       ` Nikita Pettik [this message]
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=20201117202318.GA19460@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=roman.habibov@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