From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 76E6F4696C3 for ; Thu, 30 Apr 2020 15:35:02 +0300 (MSK) Received: by mail-lf1-f54.google.com with SMTP id f8so1049731lfe.12 for ; Thu, 30 Apr 2020 05:35:02 -0700 (PDT) Date: Thu, 30 Apr 2020 15:35:00 +0300 From: Konstantin Osipov Message-ID: <20200430123500.GA6499@atlas> References: <20200213142534.GA26443@tarantool.org> <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <36e21524-35d7-9f54-5953-32863df95709@tarantool.org> Subject: Re: [Tarantool-discussions] Implicit cast for ASSIGNMENT List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Imeev Mergen Cc: tarantool-discussions@dev.tarantool.org * Imeev Mergen [20/04/30 15:13]: > Hi! Here we go again. Last time we have not come to a colclusion. > > So, I suggest these rules for implicit cast for ASSIGNMENT: > 1) Any value can be implicitly cast to ANY type. > 2) Any scalar values ​​can be implicitly cast to SCALAR type. > 3) Values ​​of numeric types can be implicitly cast to other numeric > types. SQL is strictly typed, there should be no implicit conversions between numeric types. The only possible exception is conversion of a lossless conversion of a numeric literal, e.g.: float_val = 1.1 -- implicitly convert decimal constant 1.1 to float > 4) Implicit casting is prohibited, except as described above. > > > I think that the rules for implicit casting when assigning value > of numeric type must be the same as in C. > -- Konstantin Osipov, Moscow, Russia https://scylladb.com