From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 4EC7F469719 for ; Thu, 13 Feb 2020 17:25:39 +0300 (MSK) Date: Thu, 13 Feb 2020 17:25:34 +0300 From: Mergen Imeev Message-ID: <20200213142534.GA26443@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Subject: [Tarantool-discussions] Implicit cast for ASSIGNMENT List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-discussions@dev.tarantool.org, kostja.osipov@gmail.com, pgulutzan@ocelot.ca, korablev@tarantool.org, alexander.turenko@tarantool.org, v.shpilevoy@tarantool.org, kyukhin@tarantool.org Hi all, I would like to discuss the second issue of casts in SQL. I mean implicit casting for ASSIGNMENT. For now, I suggest avoiding questions about SCALAR, as the discussion is already in progress. So, I suggest removing the current implicit casts. We can reimplement implicit casts in accordance with ANSI in issue #3836. But since priority of #3836 is low, this is most likely not going to happen for some time. At the moment, I see two ways to remove implicit casts: 1) Disable all implicit casts, except casts for numeric values. These casts will become UDCF later. 2) Disable all implicit casts. Assignment in Tarantool-SQL will work the same as in noSQL Tarantool. What do you think about this?