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 1oZRtU-0002mh-CE for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Sep 2022 07:05:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oZRtT-0005ee-6g for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Sep 2022 07:05:39 +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 1oZRtS-0005eV-N6 for pgsql-hackers@lists.postgresql.org; Sat, 17 Sep 2022 07:05:38 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oZRtP-0004jd-D6 for pgsql-hackers@postgresql.org; Sat, 17 Sep 2022 07:05:37 +0000 Received: from mail.postgrespro.ru (cyclops.postgrespro.ru [93.174.131.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 1881F21C04FB; Sat, 17 Sep 2022 10:05:33 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1663398333; bh=+3drWgavEYu0YxSBDLY4zp5CR08W4MikF/CWVUefG5Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ktDzI8rLFtqcV+e+98wXWP1/sOI3zvmZpXqqxrCKrpHaxOMeo8ux+Rtn2Z0Zd78yt /u5HpMokBFu8JK7R+fH4rKutzQTgjiozJy2plQV+tI51A5xV0kVkeGi+d0tuYmnhUi fJfEM71pOs8ABDlZs+53RC4nwMe42MuQ/NynLTIE= MIME-Version: 1.0 Date: Sat, 17 Sep 2022 10:05:32 +0300 From: Marina Polyakova To: Kyotaro Horiguchi Cc: pgsql-hackers@postgresql.org, pryzby@telsasoft.com, rjuju123@gmail.com, daniel@manitou-mail.org, AndrewBille@gmail.com, michael@paquier.xyz, peter.eisentraut@enterprisedb.com Subject: Re: ICU for global collation In-Reply-To: <20220916.171116.507864395269358149.horikyota.ntt@gmail.com> References: <6dd6db0984d86a51b7255ba79f111971@postgrespro.ru> <20220915.155210.529619933474389138.horikyota.ntt@gmail.com> <20220916.171116.507864395269358149.horikyota.ntt@gmail.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <897b08202324ea098443bf9c3231b9b2@postgrespro.ru> X-Sender: m.polyakova@postgrespro.ru Organization: Postgres Professional Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-09-16 11:11, Kyotaro Horiguchi wrote: > At Fri, 16 Sep 2022 09:49:28 +0300, Marina Polyakova > wrote in >> In continuation of options check: AFAICS the following checks in >> initdb >> >> if (locale_provider == COLLPROVIDER_ICU) >> { >> if (!icu_locale) >> pg_fatal("ICU locale must be specified"); >> >> /* >> * In supported builds, the ICU locale ID will be checked by the >> * backend during post-bootstrap initialization. >> */ >> #ifndef USE_ICU >> pg_fatal("ICU is not supported in this build"); >> #endif >> } >> >> are executed approximately when they are executed in create database >> after getting all the necessary data from the template database: > > initdb doesn't work that way, but anyway, I realized that I am > proposing to move that code in setlocales() to the caller function as > the result. I don't think setlocales() is the place for the code > because icu locale has no business with what the function does. That > being said there's no obvious reason we *need* to move the code out to > its caller. Excuse me, but could you explain your last sentence in more detail? I read that this code is not for setlocales and then - that it should not moved from here, so I'm confused... > + errmsg("encoding \"%s\" is not supported with ICU provider", > > + pg_log_error("encoding \"%s\" is not supported with ICU provider", > + pg_encoding_to_char(encodingid)); > > I might be wrong, but the messages look wrong to me. The alternatives > below might work. > > "encoding \"%s\" is not supported by ICU" > "encoding \"%s\" cannot be used for/with ICU locales" The message indicates that the selected encoding cannot be used with the ICU provider because it does not support it. But if the text of the message becomes better and clearer, I will only be glad. > + pg_log_error_hint("Rerun %s and choose a matching combination.", > + progname); > > This doesn't seem to provide users with useful information. It was commited in more verbose form: pg_log_error_hint("Rerun %s and either do not specify an encoding explicitly, " "or choose a matching combination.", -- Marina Polyakova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company