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 61E9C46970E for ; Sat, 28 Dec 2019 02:44:18 +0300 (MSK) Date: Sat, 28 Dec 2019 01:44:15 +0200 From: Nikita Pettik Message-ID: <20191227234415.GN18639@tarantool.org> References: <0164c69c939fb61b7e6255c4cb695562d05fdef5.1576071711.git.korablev@tarantool.org> <20191224002656.GA37210@tarantool.org> <056f9213-5038-c096-2b0a-cf6c85a52a8a@tarantool.org> <20191226112411.GE18639@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191226112411.GE18639@tarantool.org> 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: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org 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.