From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 549D846970E for ; Fri, 7 Feb 2020 17:40:56 +0300 (MSK) Received: by mail-lf1-f44.google.com with SMTP id t23so1675835lfk.6 for ; Fri, 07 Feb 2020 06:40:56 -0800 (PST) Date: Fri, 7 Feb 2020 17:40:54 +0300 From: Konstantin Osipov Message-ID: <20200207144054.GB4105@atlas> References: <20200121111108.GA18881@tarantool.org> <20200130185216.GC26109@atlas> <20200203113519.GA9896@tarantool.org> <20200204185011.GF1049@tarantool.org> <20200207142446.GA1110@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200207142446.GA1110@tarantool.org> Subject: Re: [Tarantool-discussions] Implicit cast for COMPARISON List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-discussions@dev.tarantool.org * Nikita Pettik [20/02/07 17:29]: > Alternatively, we can abandon this idea and operate apply comparison > rules depending purely on mp_ types of particular scalar values. But > then rules in NoSQL and SQL will be different. This would be worst thing of all. mp_type is an encoding format, which, btw, I would like to ditch from in-memory tuple format going forward (only keep for data on disk and wirte) - 'cause compression benefits it gives do not outweigh the performance slow down of variable representation or need to pack/unpack. There should be a single set of data types for SQL and NoSQL and the rules should be the same. If NoSQL types don't have some ansi features, then these features should be added to nosql, and sql should use nosql. -- Konstantin Osipov, Moscow, Russia