Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biLDJ-0002Y5-Uz for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2016 12:47:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1biLDJ-0002oP-GS for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Sep 2016 12:47:25 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1biLBu-0001GC-VY for pgsql-hackers@postgresql.org; Fri, 09 Sep 2016 12:45:59 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1biLBs-0006pa-AO for pgsql-hackers@postgresql.org; Fri, 09 Sep 2016 12:45:57 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0348520474; Fri, 9 Sep 2016 08:45:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 09 Sep 2016 08:45:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=D2ACLHbxTsxagSN SAL/wHTEu/jU=; b=e6/SoBmSzbEyjbqB32WWlB+p7EUAwCKbJwYvvde2ECtp2r9 c7qcW13QL+bBESVfAPX3SGpRQxXFLV5JxdG31mKQlKgCdXRT1+pKM65WacEI3U4r Q2Tg42Cnh4vkGdp+93KpVwuZ9SVfXmz2CzpKfGqaS77Ub57FPVVG1QlhJwvE= X-Sasl-enc: 8+16d1ktqCpmjxFKHAMxRNU6USgHmNw3JHXfnNVz6hYr 1473425154 Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 79DAFCCDCB; Fri, 9 Sep 2016 08:45:54 -0400 (EDT) Subject: Re: ICU integration To: Peter Geoghegan , Craig Ringer References: <3006.1473347760@sss.pgh.pa.us> <9caee847-7a64-a71a-d4ce-a269b04a3a8c@2ndquadrant.com> <20160909.095154.1130083428657813367.t-ishii@sraoss.co.jp> Cc: Tatsuo Ishii , Tom Lane , Doug Doole , PostgreSQL Hackers , =?UTF-8?B?RGV2cmltIEfDvG5kw7x6?= From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <08dc02e5-3347-666d-7eae-ea08b8e8a64e@2ndquadrant.com> Date: Fri, 9 Sep 2016 08:45:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 9/8/16 11:08 PM, Peter Geoghegan wrote: > In principle, and assuming I haven't gotten something wrong, it ought > to be possible to unambiguously identify a collation based on a > matching UCA version (i.e. DUCET table), plus the collation tailorings > matching exactly, even across ICU versions that happen to be based on > the same UCA version (they only seem to put out a new UCA version > about once a year [4]). It *might* be fine, practically speaking, to > assume that a collation with a matching iso-code and UCA version is > compatible forever and always across any ICU version. If not, it might > instead be feasible to write a custom fingerprinter for collation > tailorings that ran at initdb time. The documentation [0] states that the collation version covers a broad range of things. So I don't think these additional mechanisms you describe are necessary. [0]: http://userguide.icu-project.org/collation/architecture#TOC-Versioning -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers