From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (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 85720452566 for ; Sun, 17 Nov 2019 23:25:54 +0300 (MSK) From: Vladislav Shpilevoy References: <12ed4be2e7e433fdca58a43fc3b937eb9a54f52f.1573121685.git.imeevma@gmail.com> <9fe3bd05-17de-e878-4395-4d15cf2f0b38@tarantool.org> <20191107141209.GA10466@tarantool.org> <93979a0b-1708-1125-1142-74f22734b088@tarantool.org> <20191115140609.GA15961@tarantool.org> <3d76e64a-cd03-1bf1-5830-0d0b142a5e27@tarantool.org> Message-ID: <194ae7ab-61bc-797a-527e-81704ade2545@tarantool.org> Date: Sun, 17 Nov 2019 21:32:17 +0100 MIME-Version: 1.0 In-Reply-To: <3d76e64a-cd03-1bf1-5830-0d0b142a5e27@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v3 3/5] sql: introduce SET statement List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mergen Imeev Cc: tarantool-patches@dev.tarantool.org I was thinking about it, and realized, that SET is really castrated. For example: box.cfg{} box.execute('CREATE TABLE test (id INTEGER PRIMARY KEY, a BOOLEAN)') box.execute('INSERT INTO test VALUES (1, TRUE)') tarantool> box.execute('UPDATE test SET a = FALSE AND TRUE') --- - row_count: 1 ... This UPDATE SET works. Settings SET does not work: tarantool> box.execute('SET sql_full_column_names = FALSE AND TRUE;') --- - null - Keyword 'AND' is reserved. Please use double quotes if 'AND' is an identifier. ... I think we need to make them working the same. We can't expect that a user will always pass a trivial constant boolean value. Binding also does not work: tarantool> box.execute('SET sql_full_column_names = ?;', {true}) --- - null - Syntax error near '?' ... And as well, we can't force a user to always concatenate its settings into a query string. At least this is not safe. But I think this might be moved to 4621 issue. Because PRAGMA also does not understand complex expressions, nor bound parameters.