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 6925326026 for ; Thu, 17 Jan 2019 14:19:30 -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 0W5WVqbaCyN0 for ; Thu, 17 Jan 2019 14:19:30 -0500 (EST) 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 turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id BACDA25F48 for ; Thu, 17 Jan 2019 14:19:29 -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 2/2] sql: compute resulting collation for concatenation From: "n.pettik" In-Reply-To: <20190117133322.GO28204@chai> Date: Thu, 17 Jan 2019 22:19:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <652a9e6a4514a03ef93133961b09c2f5d45721d8.1547644180.git.korablev@tarantool.org> <20190117133322.GO28204@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 , Vladislav Shpilevoy > On 17 Jan 2019, at 16:33, Konstantin Osipov = wrote: >=20 > * Nikita Pettik [19/01/16 17:06]: >> According to ANSI, result of concatenation operation should derive >> collation sequence from its operands. Now it is not true: result is >> always comes with no ("none") collation. >=20 > Generally, it should be very cheap to introduce expression static > analysis phase by adding static analysis state to struct Expr. > Yes, it's a blasphemy from separation of concerns point of view > but it seems to be a lesser evil than invoking partial static > analysis here and there during code generation. >=20 > What i mean is that instead of changing signature of > sql_expr_coll() one should be able to do: >=20 > /** > * Fills expr->coll for every node in the expression tree or > * returns an appropriate error if there is a type error. *Type and collation analysis are slightly different things I guess.* > */ > int > sql_expr_static_analysis(struct Expr *expr); Implement decent static analysis pass could be not so easy as it seems to be. Firstly, I guess we should deal with https://github.com/tarantool/tarantool/issues/3861 In a nutshell, now walker uses recursive approach. Hence, due to very limited size of fiber=E2=80=99s stack we get stack overflow on not so giant expressions. One more recursive routine may make things even worse. Secondly, we should decide where to place this analysis. There is no one entry point before code generation as well as there is no strict separation between parsing and code generation. Moreover, complete AST may not be constructed at all. I=E2=80=99m simply inlining part of R. Hipp=E2=80=99s = recent respond from SQLite maling list: > SQLite does not necessarily generate a complete AST, then hand > that AST off to a code generator for evaluation, all in one neat step. > Depending on the SQL statement, the byte code may be generated using > techniques reminiscent of "syntax directed translation". Control hops > back and forth between parsing and code generation. Sections of > bytecode might generated at multiple reduce actions within the parse. In case you bless me and allow to spend extra time I can attempt at investigating this issue. Current approach at least works now.