Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bi24b-0005u6-49 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Sep 2016 16:21:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bi24a-0003jZ-H5 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Sep 2016 16:21:08 +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 1bi23D-000289-BR for pgsql-hackers@postgresql.org; Thu, 08 Sep 2016 16:19:43 +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 1bi23A-0000wP-I9 for pgsql-hackers@postgresql.org; Thu, 08 Sep 2016 16:19:41 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BE8ED202B4; Thu, 8 Sep 2016 12:19:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Sep 2016 12:19:39 -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=FqToPWt2krtilmq 6E2p+uUAC04I=; b=sGUPCPkoHxE9ZKhVbC41tHme65hHLmeLklMKge71ul2wmL2 I/En5C0VHpW5jy/dKHvPQsJhNmXo94EAoVgEywm5ELAcZOgu9Celedll6HWcSXew lR782clr8nBhYVGd/RYElvA7udINkFkY8XhYdbamglxXUCxvDQTgMTMizGDg= X-Sasl-enc: NTwB6gLrQ6Taq8ukyPfH5WJr4nTYM0QK0Ys1R1V5Woqu 1473351579 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 7FA25F29D1; Thu, 8 Sep 2016 12:19:39 -0400 (EDT) Subject: Re: ICU integration To: Tom Lane References: <85364fde-091f-bbc0-fec2-e3ede39840a6@2ndquadrant.com> <51759C7D-BE9E-4173-B5F9-EFD7B9594C2B@salesforce.com> <6008673a-e371-8437-adc0-96fba4a74028@2ndquadrant.com> <3006.1473347760@sss.pgh.pa.us> Cc: Doug Doole , Craig Ringer , pgsql-hackers From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <9caee847-7a64-a71a-d4ce-a269b04a3a8c@2ndquadrant.com> Date: Thu, 8 Sep 2016 12:19:39 -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: <3006.1473347760@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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:16 AM, Tom Lane wrote: > This is a problem, if ICU won't guarantee cross-version compatibility, > because it destroys the argument that moving to ICU would offer us > collation behavior stability. It would offer a significant upgrade over the current situation. First, it offers stability inside the same version. Whereas glibc might change a collation in a minor upgrade, ICU won't do that. And the postgres binary is bound to a major version of ICU by the soname (which changes with every major release). So this would avoid the situation that a simple OS update could break collations. Second, it offers a way to detect that something has changed. With glibc, you don't know anything unless you read the source diffs. With ICU, you can compare the collation version before and after and at least tell the user that they need to refresh indexes or whatever. -- 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