From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp47.i.mail.ru (smtp47.i.mail.ru [94.100.177.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id D765E469719 for ; Thu, 20 Feb 2020 09:15:09 +0300 (MSK) Date: Thu, 20 Feb 2020 09:15:05 +0300 From: Kirill Yukhin Message-ID: <20200220061505.kzbzgcgyjx6b4nkp@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v2 0/4] Don't truncate float in update List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Hello, On 04 фев 23:53, Vladislav Shpilevoy wrote: > The patchset fixes float value truncation in > tuple/space:update/upsert. First commit fixes the actual issue, > but introduces another bug that a float value can be stored into a > field having double type in its format. > > The rest 3 commits fix this new bug. > > However, there is an alternative how these 3 could be done. My > solution is that I calculate the result types in > xrow_update_*_store() functions. Because of that I don't know the > types during xrow_update_*_sizeof(), and it needs to return the > maximal possible size instead of exact size. The alternative is to > calculate types during sizeof. It would allow to return the exact > size. But it also would complicate the code. I can implement this > option if it looks better. > > Branch: http://github.com/tarantool/tarantool/tree/gerold103/gh-4701-update-float-truncate > Issue: https://github.com/tarantool/tarantool/issues/4701 LGTM. I've checked your patchset into 2.3 and master. -- Regards, Kirill Yukhin