Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bi15N-0003Dr-LL for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Sep 2016 15:17:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bi15N-0008HS-2s for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Sep 2016 15:17:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bi140-0006gY-7z for pgsql-hackers@postgresql.org; Thu, 08 Sep 2016 15:16:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bi13u-0004ap-VT for pgsql-hackers@postgresql.org; Thu, 08 Sep 2016 15:16:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u88FG0hD003007; Thu, 8 Sep 2016 11:16:00 -0400 From: Tom Lane To: Peter Eisentraut cc: Doug Doole , Craig Ringer , pgsql-hackers Subject: Re: ICU integration In-reply-to: <6008673a-e371-8437-adc0-96fba4a74028@2ndquadrant.com> References: <85364fde-091f-bbc0-fec2-e3ede39840a6@2ndquadrant.com> <51759C7D-BE9E-4173-B5F9-EFD7B9594C2B@salesforce.com> <6008673a-e371-8437-adc0-96fba4a74028@2ndquadrant.com> Comments: In-reply-to Peter Eisentraut message dated "Wed, 07 Sep 2016 08:53:22 -0400" Date: Thu, 08 Sep 2016 11:16:00 -0400 Message-ID: <3006.1473347760@sss.pgh.pa.us> X-Pg-Spam-Score: -3.0 (---) 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 Peter Eisentraut writes: > On 9/6/16 1:40 PM, Doug Doole wrote: >> We carried the ICU version numbers around on our collation and locale >> IDs (such as fr_FR%icu36) . The database would load multiple versions of >> the ICU library so that something created with ICU 3.6 would always be >> processed with ICU 3.6. This avoided the problems of trying to change >> the rules on the user. (We'd always intended to provide tooling to allow >> the user to move an existing object up to a newer version of ICU, but we >> never got around to doing it.) In the code, this meant we were >> explicitly calling the versioned API so that we could keep the calls >> straight. > I understand that in principle, but I don't see operating system > providers shipping a bunch of ICU versions to facilitate that. They > will usually ship one. I agree with that estimate, and I would further venture that even if we wanted to bundle ICU into our tarballs, distributors would rip it out again on security grounds. I am dead certain Red Hat would do so; less sure that other vendors have similar policies, but it seems likely. They don't want to have to fix security bugs in more than one place. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers