From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (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 63591445320 for ; Tue, 7 Jul 2020 01:06:26 +0300 (MSK) Date: Mon, 6 Jul 2020 22:06:25 +0000 From: Nikita Pettik Message-ID: <20200706220625.GD22427@tarantool.org> References: <20200629125630.GA27240@tarantool.org> <20200705142851.GB135859@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200705142851.GB135859@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v3 4/8] sql: replace ApplyType by CheckType for IN operator List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org On 05 Jul 17:28, Mergen Imeev wrote: > On Mon, Jun 29, 2020 at 12:56:30PM +0000, Nikita Pettik wrote: > > On 25 Jun 18:17, imeevma@tarantool.org wrote: > > > index f7681640e..a2147b0e8 100755 > > > --- a/test/sql-tap/in3.test.lua > > > +++ b/test/sql-tap/in3.test.lua > > > @@ -1,6 +1,6 @@ > > > #!/usr/bin/env tarantool > > > test = require("sqltester") > > > -test:plan(29) > > > +test:plan(28) > > > > > > --!./tcltestrunner.lua > > > -- 2007 November 29 > > > @@ -322,18 +322,6 @@ test:do_test( > > > -- > > > }) > > > > > > -test:do_test( > > > - "in3-3.3", > > > - function() > > > - -- Logically, numeric affinity is applied to both sides before > > > - -- the comparison, but index can't be used. > > > - return exec_neph(" SELECT x IN (SELECT b FROM t1) FROM t2 ") > > > - end, { > > > - -- > > > - 1, true > > > - -- > > > - }) > > > - > > > > I'd rather not drop this test. It's about scalar-numeric types > > interaction. Mb it is not the most suitable place for such test, > > but make sure this scenario is covered somewhere else. > > > I added a few tests with SCALARS in 'sql: remove implicit > cast for comparison' commit. However, there is a lot > problems with SCALARS at the moment. Давай с этим что-то делать. Проблемы где-то описаны? Если нет, давай подробно разберем и заведем тикет(ы). Иначе это звучит как "idgs потом кто-нибудь это разгребет". В тикете 4230 есть пункт про скаляр, но мы почему-то обходим его, оставляя проблему as is. > > The rest is OK as obvious. > >