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 C66942867B for ; Mon, 26 Aug 2019 19:25:18 -0400 (EDT) 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 QC0qKC4e-ZMh for ; Mon, 26 Aug 2019 19:25:18 -0400 (EDT) Received: from smtp55.i.mail.ru (smtp55.i.mail.ru [217.69.128.35]) (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 8557A28676 for ; Mon, 26 Aug 2019 19:25:18 -0400 (EDT) Date: Tue, 27 Aug 2019 02:25:00 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH v2 1/3] box: rfc for stacked diagnostic area in Tarantool Message-ID: <20190826232500.zsmwfggte2fkd4ae@tkn_work_nb> References: <7b663975f0307541a6751bde10547fc2c13b5679.1566553968.git.kshcherbatov@tarantool.org> <20190826222607.GA1189@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190826222607.GA1189@atlas> 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: Konstantin Osipov Cc: Kirill Shcherbatov , tarantool-patches@freelists.org, georgy@tarantool.org, Peter Gulutzan On Tue, Aug 27, 2019 at 01:26:07AM +0300, Konstantin Osipov wrote: > * Kirill Shcherbatov [19/08/23 13:03]: > > Part of #1148 > > --- > > doc/rfc/1148-stacked-diagnostics.md | 175 ++++++++++++++++++++++++++++ > > 1 file changed, 175 insertions(+) > > create mode 100644 doc/rfc/1148-stacked-diagnostics.md > > as I mentioned before, lgtm. I agree with PeterG comments, but I > think we can worry about them when we get to implementing SQL > warnings. I think the important question here is when we clear a diagnostic area (if we ever want to decide now anything about warnings). Say, we possibly will need to entirely split warning stacks from the error stack and possibly will need to operate on several warning stacks. I'm tentative that we can decide now whether we should store warnings within the same stack as errors or not. Maybe we should postpone all warnings questions now and concentrate on errors within the scope #1148. WBR, Alexander Turenko.