From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: Nikita Pettik <korablev@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 4/6] sql: extend result set with nullability Date: Fri, 6 Dec 2019 01:00:14 +0100 [thread overview] Message-ID: <53b2d81f-2287-8916-56e4-d985221e5ff1@tarantool.org> (raw) In-Reply-To: <20191205115051.GA56807@tarantool.org> Thanks for the fixes! On 05/12/2019 12:50, Nikita Pettik wrote: > On 28 Nov 23:41, Vladislav Shpilevoy wrote: >> Thanks for the patch! >> >> You added a leading whitespace to the commit title. > > Fixed. > >> Here is a strange example: >> >> box.cfg{} >> s = box.schema.create_space('TEST', { >> format = {{'ID', 'unsigned'}, {'COL', 'unsigned', is_nullable = true}} >> }) >> pk = s:create_index('pk', {parts = {{'ID'}, {'COL', is_nullable = false}}}) >> >> In that example I defined a 'false-nullable' column. It >> is nullable in the space format, but is not in the >> index format. The strictest rule wins, so it is not nullable >> after all. That can be seen in struct tuple_format. SQL says, >> that it is nullable. But this is not a real problem. Perhaps >> this might be even right. > > If it was up to me, I would disallow such possible inconsistency > between space and index formats. It turns out to be quite > confusing. I believe there's historical reason for that, tho. There is a still actual reason - incremental alter. When you have a space format and an index both specifying is_nullable, sometimes you need a way to change the is_nullable value. And if it would need to be the same everywhere, you would need to drop all the related indexes, change nullability in the space format, and recreate the indexes. This is long because of indexes rebuilding. With the current implementation you can change nullability without drop of the indexes. Step by step. And it has nothing to do with transactional ddl. >>> diff --git a/src/box/execute.c b/src/box/execute.c >>> index 20bfd0957..98812ae1e 100644 >>> --- a/src/box/execute.c >>> +++ b/src/box/execute.c >>> @@ -267,8 +267,10 @@ error: >>> region_truncate(region, svp); >>> return -1; >>> } >>> + >>> static size_t >>> -metadata_map_sizeof(const char *name, const char *type, const char *coll) >>> +metadata_map_sizeof(const char *name, const char *type, const char *coll, >>> + int nullable) >> >> 1. Please, rename to 'is_nullable'. Here and in other places. > > IMHO 'is_' prefix implies boolean value, meanwhile here nullable > is in fact three-valued: 0, 1 implies nullable/not nullable, -1 > is unknown (for columns of resulting set that are complex expressions). > So that we can avoid sending 'nullable' property in meta for expressions, > but always set it for columns. Hence, I omitted is_ prefix on purpose. Well, then you need to omit it in sql_column_is_nullable() too, because it returns 3 values.
next prev parent reply other threads:[~2019-12-06 0:00 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-27 12:15 [Tarantool-patches] [PATCH 0/6] sql: extend response metadata Nikita Pettik 2019-11-27 12:15 ` [Tarantool-patches] [PATCH 1/6] sql: refactor resulting set metadata Nikita Pettik 2019-11-28 22:41 ` Vladislav Shpilevoy 2019-12-05 11:39 ` Nikita Pettik 2019-12-05 23:58 ` Vladislav Shpilevoy 2019-12-06 12:48 ` Nikita Pettik 2019-12-17 13:23 ` Sergey Ostanevich 2019-11-27 12:15 ` [Tarantool-patches] [PATCH 2/6] sql: fix possible null dereference in sql_expr_coll() Nikita Pettik 2019-11-28 22:42 ` Vladislav Shpilevoy 2019-12-05 11:40 ` Nikita Pettik 2019-12-05 23:59 ` Vladislav Shpilevoy 2019-12-06 12:48 ` Nikita Pettik 2019-12-17 13:30 ` Sergey Ostanevich 2019-12-17 14:44 ` Nikita Pettik 2019-12-17 19:53 ` Nikita Pettik 2019-11-27 12:15 ` [Tarantool-patches] [PATCH 3/6] sql: extend result set with collation Nikita Pettik 2019-11-28 22:41 ` Vladislav Shpilevoy 2019-12-05 11:50 ` Nikita Pettik 2019-12-18 11:08 ` Sergey Ostanevich 2019-12-24 0:44 ` Nikita Pettik 2019-11-27 12:15 ` [Tarantool-patches] [PATCH 4/6] sql: extend result set with nullability Nikita Pettik 2019-11-28 22:41 ` Vladislav Shpilevoy 2019-12-05 11:50 ` Nikita Pettik 2019-12-06 0:00 ` Vladislav Shpilevoy [this message] 2019-12-06 12:49 ` Nikita Pettik 2019-12-18 13:31 ` Sergey Ostanevich 2019-11-27 12:15 ` [Tarantool-patches] [PATCH 5/6] sql: extend result set with autoincrement Nikita Pettik 2019-11-28 22:41 ` Vladislav Shpilevoy 2019-12-05 11:51 ` Nikita Pettik 2019-12-18 15:17 ` Sergey Ostanevich 2019-12-24 0:47 ` Nikita Pettik 2019-11-27 12:15 ` [Tarantool-patches] [PATCH 6/6] sql: extend result set with alias Nikita Pettik 2019-11-28 22:41 ` Vladislav Shpilevoy 2019-12-05 11:51 ` Nikita Pettik 2019-12-06 0:02 ` Vladislav Shpilevoy 2019-12-06 12:50 ` Nikita Pettik 2019-12-06 21:52 ` Vladislav Shpilevoy 2019-12-19 15:17 ` Sergey Ostanevich 2019-12-24 0:27 ` Nikita Pettik 2019-11-28 22:55 ` [Tarantool-patches] [PATCH 0/6] sql: extend response metadata Vladislav Shpilevoy
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=53b2d81f-2287-8916-56e4-d985221e5ff1@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=korablev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 4/6] sql: extend result set with nullability' \ /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