From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [tarantool-patches] Re: [PATCH] Add MsgPack ext types handling. References: <20190423113732.20786-1-sergepetrenko@tarantool.org> <20190423122146.GA5668@chai> <39783BF9-0E1F-4AB0-B538-B7F2A2A123FF@tarantool.org> <20190423134420.GB6068@chai> From: Vladislav Shpilevoy Message-ID: <600c2d20-c708-5f74-e341-696d679f23e5@tarantool.org> Date: Tue, 23 Apr 2019 16:54:51 +0300 MIME-Version: 1.0 In-Reply-To: <20190423134420.GB6068@chai> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit To: tarantool-patches@freelists.org, Konstantin Osipov , Serge Petrenko Cc: Vladimir Davydov List-ID: On 23/04/2019 16:44, Konstantin Osipov wrote: > * Serge Petrenko [19/04/23 16:05]: >> >> >>> 23 апр. 2019 г., в 15:21, Konstantin Osipov написал(а): >>> >>> * Serge Petrenko [19/04/23 15:09]: >>> >>> I mentioned before that this would break all clients. >>> >>> It's high time to reconsider our in-memory storage format and make >>> it different from serialization format: we're seeing significant >>> performance penalty with serialization to and from msgpack in SQL, >>> and DECIMAL is a yet another blow on the single-format-approach: >>> our clients are simply not prepared to handle non-standard >>> extensions. >>> >>> Let's investigate what it takes to store decimal as an mp ext, and >>> serialize as mp string. >> >> Well, we can do this, but how can clients distinguish decimal and string then? > > From result set metadata or, more generally, from schema. Then I will be able to violate format via insertion of strings into decimal column. > > > > -- > Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 > http://tarantool.io - www.twitter.com/kostja_osipov >