Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4ZRw-0003rv-FI for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Jan 2022 02:21:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n4ZRu-00021A-AG for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Jan 2022 02:21:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4ZRt-000210-Qj for pgsql-hackers@lists.postgresql.org; Tue, 04 Jan 2022 02:21:17 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n4ZRm-0000zN-St for pgsql-hackers@postgresql.org; Tue, 04 Jan 2022 02:21:16 +0000 Received: by mail-pf1-x42a.google.com with SMTP id v11so30901754pfu.2 for ; Mon, 03 Jan 2022 18:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=V4Y+ksLCU9RgCGlIPofUxT5HRvBMzTDZVWkWcUJCa5s=; b=Gw5o1HVpVMcaqM1OB37LxE6B3um+WDULiCALUlWCgVEbMQoMtTFZaX3SDZnX8zeXXJ uG7fxSDzxtcsOptTmzc5UvxUexeV+JTH1ooVta41ee+A2oP+bqUtg0mTQkhuOL89Rof4 MUjxYcmq2+AKucQQIjq4zF+Rn7j9i86+Ec24yCQtLPp52XG4WctjQvgepoQvMlR1d+lh 8SAAQY576ClbIKkcBv4c45uc+dFk+DAV/J+iCL/friNr8bKUnINNeV8Gskw5S7pTKj/X jpXqalNyj+bm1INkUDr2p+uV0eotP/cuVN0PO2hk8XhdRf2SHFE4DGC6/ZQTNsv6UwTZ z+ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=V4Y+ksLCU9RgCGlIPofUxT5HRvBMzTDZVWkWcUJCa5s=; b=fxNzX9MokSK4YCZfhzvDn3EDfRvl4CV+CgjqKf0PkLQym8kHsxkZrvqC93yE9U/ans 06kdobaZooitGCjOlFIt8wozdu2imUf/Zc6RcTKKF7RoEW4it4t9lltT3A9xxN8Uk80l aul+yOxMPbyY9TVTuakd3UfVXpvFtCre9jG1YbDWzwySaNLwOzgibVVHi6acL/2rTgiU dXrBWUcQXNFpL4E0UyadcrknOCUhjL8EfPLEEAYS3BugCw0NOdlnJX7wU/flcSeibyD/ GVXzjYFx2R6aZpLQF3yzluos4+asSqGsJDcbWwrqNg0m2nJOtpAqa2F1Ir4GLZiPHWCZ APxw== X-Gm-Message-State: AOAM530QK5rZQeji1QIQowr9Ff9WclvfaffASqsWbZXOwhY5Dh6kDHjf PUlvkIJz1VsF+7wiMEDby3MpVJ4YVJE= X-Google-Smtp-Source: ABdhPJxlCdrvx8AiGJNfEt76AiwRjRsdZN+QqAn+cqU/vH+pDg9bPUf3uSRcmdaFI1o/1d/7F1AkpQ== X-Received: by 2002:a63:784:: with SMTP id 126mr42977992pgh.530.1641262868897; Mon, 03 Jan 2022 18:21:08 -0800 (PST) Received: from jrouhaud (111-243-93-144.dynamic-ip.hinet.net. [111.243.93.144]) by smtp.gmail.com with ESMTPSA id h19sm38982130pfh.30.2022.01.03.18.21.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jan 2022 18:21:08 -0800 (PST) Date: Tue, 4 Jan 2022 10:21:04 +0800 From: Julien Rouhaud To: Peter Eisentraut Cc: pgsql-hackers , Daniel Verite Subject: Re: ICU for global collation Message-ID: References: <374f8048-9d87-462c-a8aa-d02ffca6525f@manitou-mail.org> <525ef44f-52bf-505f-a491-07835d039424@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <525ef44f-52bf-505f-a491-07835d039424@enterprisedb.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Thu, Dec 30, 2021 at 01:07:21PM +0100, Peter Eisentraut wrote: > > So this is a different approach: If you choose ICU as the default locale for > a database, you still need to specify lc_ctype and lc_collate settings, as > before. Unlike in the previous patch, where the ICU collation name was > written in datcollate, there is now a third column (daticucoll), so we can > store all three values. This fixes the described problem. Other than that, > once you get all the initial settings right, it basically just works: The > places that have ICU support now will use a database-wide ICU collation if > appropriate, the places that don't have ICU support continue to use the > global libc locale settings. That looks sensible to me. > @@ -2774,6 +2776,7 @@ dumpDatabase(Archive *fout) > appendPQExpBuffer(dbQry, "SELECT tableoid, oid, datname, " > "(%s datdba) AS dba, " > "pg_encoding_to_char(encoding) AS encoding, " > + "datcollprovider, " This needs to be in a new pg 15+ branch, not in the pg 9.3+. > - if (!lc_collate_is_c(collid) && collid != DEFAULT_COLLATION_OID) > - mylocale = pg_newlocale_from_collation(collid); > + if (!lc_collate_is_c(collid)) > + { > + if (collid != DEFAULT_COLLATION_OID) > + mylocale = pg_newlocale_from_collation(collid); > + else if (default_locale.provider == COLLPROVIDER_ICU) > + mylocale = &default_locale; > + } There are really a lot of places with this new code. Maybe it could be some new function/macro to wrap that for the normal case (e.g. not formatting.c)?