From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 52E366EC58; Thu, 27 May 2021 18:33:12 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 52E366EC58 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1622129592; bh=SyFSviSJnFZ9T8bAb+v3WdGRf7b2ZX5f2P9DOHfxlPk=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=qv2NUYofGed1731600pDmy5QyAn8y4PFdtRITqac4cLH0MgEABlnEg5CvnlST1gEQ dSBb12H8licgs2D+2Gzkvf7maVSia08VTYBpn4BntAXoZojTp8priFgHbRdFiyRmaK Q8cP6V5nsg66qMDnmLh+Mptu54xxHs/sRyWrBwnU= Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (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 7A6466EC58 for ; Thu, 27 May 2021 18:33:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7A6466EC58 Received: by smtpng1.m.smailru.net with esmtpa (envelope-from ) id 1lmI0U-0000pz-D4; Thu, 27 May 2021 18:33:10 +0300 Date: Thu, 27 May 2021 18:33:09 +0300 To: Timur Safin Cc: 'Vladislav Shpilevoy' , TML Message-ID: <20210527153309.GA220955@tarantool.org> References: <9d53f29d460d7a4194cb3f95de4b5a4016453db3.1621503852.git.imeevma@gmail.com> <2cf25c21-9522-446d-3cf9-d36e0523d24b@tarantool.org> <20210525141313.GA81084@tarantool.org> <158401d751b9$82223b00$8666b100$@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <158401d751b9$82223b00$8666b100$@tarantool.org> X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9157EECD0FDB90B9A2D08AB5A5A51250A4DB392EDF99D404500894C459B0CD1B934F7063C2AAC2C0A7574FEF9FF2BEF027472CD8E138D64E14E552D6BF4A3C874 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE70312E9A300D47E3BEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063707C4856229E8E7E48638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8A3BD42FB202FA62472540A7F12AAA2FE117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18BDFBBEFFF4125B51D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B62CFFCC7B69C47339089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5271CECE046797BA3D009D494DA35DF248570F134B61CB32FD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75E3127721F5A72C97410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34D8C933888226C841FCE056FE07243FD47526FD18132366A8614D8B0FA2317BA888163FDBF021324A1D7E09C32AA3244CC2EB3D3509A7D3A2867E120BAF7178AA7101BF96129E4011FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojywAFAsvjBJgrQQBCQyhI2Q== X-Mailru-Sender: 689FA8AB762F73936BC43F508A06382208EE39BCC4D10AA2370E3ADF926E8BA983D72C36FC87018B9F80AB2734326CD2FB559BB5D741EB96352A0ABBE4FDA4210A04DAD6CC59E33667EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 1/1] sql: introduce UUID field type X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mergen Imeev via Tarantool-patches Reply-To: Mergen Imeev Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi! Thank you for suggestions. My answers below. On Wed, May 26, 2021 at 01:58:41AM +0300, Timur Safin wrote: > There is one major issue I'd like to discuss, please see below... > > : From: Mergen Imeev > : Subject: Re: [Tarantool-patches] [PATCH 1/1] sql: introduce UUID field type > : > ... > > : +static inline int > : +str_to_uuid(struct Mem *mem) > : +{ > : + assert(mem->type == MEM_TYPE_STR); > : + struct tt_uuid uuid; > : + if (mem->n != UUID_STR_LEN || > : + tt_uuid_from_string(tt_cstr(mem->z, mem->n), &uuid) != 0) > > Here lies the limitation I've specifically wanted to avoid and put > below to RFC: > > "The most complete implementation seemingly is in PostgreSQL, > which allows various relaxed formats for string literals > which may be accepted as UUID - the plan is to be as close > as possible to PostgreSQL here." > > Checking for UUID_STR_LEN restricts only to 1 specific form with > dashes in specific positions, but we would rather want to allow > relaxed formats also, with some dashes omitted. Also with optional > braces around. i.e. putting this as regexp > > \{?[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}\}? > > And yes, I mean we need to reimplement tt_uuid_from_string() differently. > (If you were asking me then I'd use RE2C for that purpose, but that up > to you) > Addition of support of other versions of UUID should not be done as part of this issue, since it is problem of BOX, not just SQL. > : + return -1; > : + mem_set_uuid(mem, &uuid); > : + return 0; > : +} > : + > : static inline int > : str_to_bool(struct Mem *mem) > : { > ... > : diff --git a/src/box/sql/mem.h b/src/box/sql/mem.h > : index 15d97da0e..b3cd5c545 100644 > : --- a/src/box/sql/mem.h > : +++ b/src/box/sql/mem.h > : @@ -30,6 +30,7 @@ > : * SUCH DAMAGE. > : */ > : #include "box/field_def.h" > : +#include "uuid/tt_uuid.h" > : > : struct sql; > : struct Vdbe; > : @@ -47,10 +48,11 @@ enum mem_type { > : MEM_TYPE_MAP = 1 << 6, > : MEM_TYPE_BOOL = 1 << 7, > : MEM_TYPE_DOUBLE = 1 << 8, > : - MEM_TYPE_INVALID = 1 << 9, > : - MEM_TYPE_FRAME = 1 << 10, > : - MEM_TYPE_PTR = 1 << 11, > : - MEM_TYPE_AGG = 1 << 12, > : + MEM_TYPE_UUID = 1 << 9, > : + MEM_TYPE_INVALID = 1 << 10, > : + MEM_TYPE_FRAME = 1 << 11, > : + MEM_TYPE_PTR = 1 << 12, > : + MEM_TYPE_AGG = 1 << 13, > > I guess there should be no incompatibility problems here, but just > in case I ask - why did you insert new constant to the middle of prior list? > Before MEM_TYPE_INVALID are types that are accesisble to user. Starting with MEM_TYPE_INVALID are for internal use. > Also I see there is another omission from RFC - there is nothing added > for SQL built-in support to generate UUID from within SQL mode. > > "Introduce UUID([version#]) functions which would allow generating > any particular type of GUID. If version argument is omitted then > we generate UUID v4 (as used by default in box);" > I will add this function. > Regards, > Timur >