From: "n.pettik" <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Konstantin Osipov <kostja@tarantool.org> Subject: [tarantool-patches] Re: [PATCH 5/6] sql: introduce extended range for INTEGER type Date: Wed, 24 Jul 2019 19:54:01 +0300 [thread overview] Message-ID: <01A073A1-0F44-4A8C-A282-509BC0C74CA3@tarantool.org> (raw) In-Reply-To: <20190724155923.GA1031@atlas> > On 24 Jul 2019, at 18:59, Konstantin Osipov <kostja@tarantool.org> wrote: > > * Nikita Pettik <korablev@tarantool.org> [19/06/07 23:30]: >> @@ -72,11 +72,11 @@ execute('SELECT ?, ?, ?', {1, 2, 3}) >> --- >> - metadata: >> - name: '?' >> - type: INTEGER >> + type: UNSIGNED >> - name: '?' >> - type: INTEGER >> + type: UNSIGNED >> - name: '?' >> - type: INTEGER >> + type: UNSIGNED >> rows: >> - [1, 2, 3] > > Nikita, > > I know this decision came after you coded most of the patch, but > we agreed that unsigned integer literals should still have > "INTEGER" type, not "UNSIGNED", since INTEGER in tarantool fully > covers UNSIGNED range. Yep, I remember that and fixed that for literals: tarantool> select 1 --- - metadata: - name: '1' type: integer rows: - [1] … But failed (simply forgot) to fix that for binding values. So, juts want to clarify: we never set “UNSIGNED” type for literals, even if they are in range [2^63, 2^64-1], right? If so, patch turns out to be pretty simple. > This leads to fewer surprises to users, e.g. when calculating > expression types. Could you please fix this? > > -- > Konstantin Osipov, Moscow, Russia >
next prev parent reply other threads:[~2019-07-24 16:54 UTC|newest] Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-07 15:37 [tarantool-patches] [PATCH 0/6] Introduce UNSIGNED type in SQL Nikita Pettik 2019-06-07 15:37 ` [tarantool-patches] [PATCH 1/6] sql: refactor sql_atoi64() Nikita Pettik 2019-06-11 21:11 ` [tarantool-patches] " Vladislav Shpilevoy 2019-07-01 14:20 ` n.pettik 2019-07-01 21:53 ` Vladislav Shpilevoy 2019-07-05 16:32 ` n.pettik 2019-06-07 15:37 ` [tarantool-patches] [PATCH 2/6] sql: separate VDBE memory holding positive and negative ints Nikita Pettik 2019-06-11 21:11 ` [tarantool-patches] " Vladislav Shpilevoy 2019-07-01 14:21 ` n.pettik 2019-07-01 21:53 ` Vladislav Shpilevoy 2019-07-05 16:33 ` n.pettik 2019-06-07 15:37 ` [tarantool-patches] [PATCH 3/6] sql: refactor arithmetic operations to support unsigned ints Nikita Pettik 2019-06-11 21:11 ` [tarantool-patches] " Vladislav Shpilevoy 2019-07-01 14:21 ` n.pettik 2019-07-01 21:53 ` Vladislav Shpilevoy 2019-07-05 16:36 ` n.pettik 2019-07-10 22:49 ` Vladislav Shpilevoy 2019-07-17 12:24 ` n.pettik 2019-06-07 15:37 ` [tarantool-patches] [PATCH 4/6] sql: make built-in functions operate on unsigned values Nikita Pettik 2019-06-11 21:11 ` [tarantool-patches] " Vladislav Shpilevoy 2019-07-01 14:21 ` n.pettik 2019-07-01 21:53 ` Vladislav Shpilevoy 2019-07-05 16:36 ` n.pettik 2019-07-10 22:49 ` Vladislav Shpilevoy 2019-07-17 0:53 ` n.pettik 2019-06-07 15:37 ` [tarantool-patches] [PATCH 5/6] sql: introduce extended range for INTEGER type Nikita Pettik 2019-06-11 21:11 ` [tarantool-patches] " Vladislav Shpilevoy 2019-07-01 14:21 ` n.pettik 2019-07-01 21:53 ` Vladislav Shpilevoy 2019-07-24 15:59 ` Konstantin Osipov 2019-07-24 16:54 ` n.pettik [this message] 2019-07-24 17:09 ` Konstantin Osipov 2019-06-07 15:37 ` [tarantool-patches] [PATCH 6/6] sql: allow to specify UNSIGNED column type Nikita Pettik 2019-07-01 21:53 ` [tarantool-patches] " Vladislav Shpilevoy 2019-07-05 16:36 ` n.pettik 2019-07-10 22:49 ` Vladislav Shpilevoy 2019-07-11 21:25 ` Vladislav Shpilevoy 2019-07-17 0:53 ` n.pettik 2019-07-18 20:18 ` Vladislav Shpilevoy 2019-07-18 20:56 ` n.pettik 2019-07-18 21:08 ` Vladislav Shpilevoy 2019-07-18 21:13 ` Vladislav Shpilevoy 2019-07-22 10:20 ` n.pettik 2019-07-22 19:17 ` Vladislav Shpilevoy 2019-07-22 10:20 ` n.pettik 2019-07-17 0:54 ` n.pettik 2019-07-18 20:18 ` Vladislav Shpilevoy 2019-08-06 19:36 ` n.pettik 2019-07-24 13:01 ` [tarantool-patches] Re: [PATCH 0/6] Introduce UNSIGNED type in SQL Kirill Yukhin
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=01A073A1-0F44-4A8C-A282-509BC0C74CA3@tarantool.org \ --to=korablev@tarantool.org \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH 5/6] sql: introduce extended range for INTEGER type' \ /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