From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (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 2905946970E for ; Sat, 28 Dec 2019 12:29:01 +0300 (MSK) References: <0164c69c939fb61b7e6255c4cb695562d05fdef5.1576071711.git.korablev@tarantool.org> <20191224002656.GA37210@tarantool.org> <056f9213-5038-c096-2b0a-cf6c85a52a8a@tarantool.org> <20191226112411.GE18639@tarantool.org> <20191227234415.GN18639@tarantool.org> From: Vladislav Shpilevoy Message-ID: <865a9c92-c814-3c6a-2f9d-f0432beb3a2f@tarantool.org> Date: Sat, 28 Dec 2019 12:29:00 +0300 MIME-Version: 1.0 In-Reply-To: <20191227234415.GN18639@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH v2 6/6] sql: extend result set with alias List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nikita Pettik Cc: tarantool-patches@dev.tarantool.org Ok, understood, thanks for working on this and checking these options. On 28/12/2019 02:44, Nikita Pettik wrote: > On 26 Dec 14:24, Nikita Pettik wrote: >> On 24 Dec 16:34, Vladislav Shpilevoy wrote: >>> Here are solutions with which I am good: >>> >>> - Keep the name as is, and add a new column meaning the original >>> expression: 'orig_name', 'oname', 'span', 'column', 'expr', etc. >>> In that case we don't break anything, we satisfy the driver, and >>> 'full_metadata' only adds new fields. It does not change the >>> behaviour of always present columns. >>> >>> - Or we could break the 'name' column a little, as you proposed - >>> always return it as if AS is not specified, even in short metadata. >>> In the full metadata it still will return the original expression, >>> but we add a 'label' column, which returns either alias or name. >> >> I am going to implement last option. > > Okay, I've tried but it turned out to be not so easy (to be more > precise - not easy at all). The problem lies in views. > We store aliases as view column names. So changing names may > (most likely) make already existing view unable to be queried. > There's simple reason for using aliases as field names: > in case spans are taken for names, users won't be able to select > columns by names: > > CREATE VIEW v1 AS SELECT a+1 FROM t; -- 'a+1' is a column name > SELECT a+1 FROM v1 -- fails: can't resolve field 'A' since real > field's name is 'a+1' (a+1 is considered > to be expression, not id). > > We might think making exeption in name/label rule for views, > but from functional point of view there's no difference between > view and casual select, since first step of execution of > SELECT ... FROM VIEW ... is substitution of view body into select. > > So I have to reject my initial plan and instead I am going > to follow first option from your suggestion. > >