From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CE5CF26936 for ; Mon, 11 Feb 2019 14:01:00 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnTQ2pc2lifO for ; Mon, 11 Feb 2019 14:01:00 -0500 (EST) Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 1416B2692C for ; Mon, 11 Feb 2019 14:00:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: [tarantool-patches] Re: [PATCH] sql: remove tests on ORDER BY/LIMIT + DELETE From: "n.pettik" In-Reply-To: <20190211130953.GC20767@chai> Date: Mon, 11 Feb 2019 22:00:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3E8E578A-52BB-496C-B448-4C2DEDAA0E05@tarantool.org> References: <20190204153458.12559-1-ivan.koptelov@tarantool.org> <20190208173817.GJ4588@chai> <22B8320B-6F03-4064-A034-AA7545C7BA4B@tarantool.org> <20190211130953.GC20767@chai> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: Konstantin Osipov > On 11 Feb 2019, at 16:09, Konstantin Osipov = wrote: >=20 > * n.pettik [19/02/09 08:47]: >>> Why ever delete tests? Why not let them (expectedly) fail? >> Could you please clarify the purpose of such tests? >=20 > In this particular case I don't entirely rule out the possibility > of these features re-appearing in our product. Are you kidding? It was you who supported idea of removing this feature: =E2=80=98=E2=80=99' You can always use WHERE pk IN (subquery expr) - this is the standard = alternative. ORDER BY ... LIMIT is only useful if your optimizer is very weak, = otherwise you can do it efficiently with a standard compliant SQL, in = relational spirit. =E2=80=98'' But OK, even if we decided to enable this thing, it wouldn=E2=80=99t be possible without implementing it from a scratch. Almost all code related to ORDER BY + DELETE was removed a long ago, only a few lines remained. And even those lines haven=E2=80=99t been kept up to date during numerous refactoring/reworking patches (aka dead code). Hence, those tests are completely useless and there is no chance that they will be turned on again someday.