Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdsVS-0064i7-0n for pgsql-general@arkaria.postgresql.org; Thu, 08 Jan 2026 16:05:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vdsVQ-002yLW-2m for pgsql-general@arkaria.postgresql.org; Thu, 08 Jan 2026 16:05:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdsVP-002yLO-2r for pgsql-general@lists.postgresql.org; Thu, 08 Jan 2026 16:05:01 +0000 Received: from fout-a2-smtp.messagingengine.com ([103.168.172.145]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdsVO-004uaw-3B for pgsql-general@postgresql.org; Thu, 08 Jan 2026 16:04:59 +0000 Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfout.phl.internal (Postfix) with ESMTP id EAD05EC0053; Thu, 8 Jan 2026 11:04:57 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Thu, 08 Jan 2026 11:04:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1767888297; x=1767974697; bh=VcRgVy/GzIH64VlQ57dTOXDnYIRcVGkKFnjM+UXx0dY=; b= DLKiuQ2kArzy2LyCLVr/gNG3XWOa6whbr993SAbUDv/n7dykRvU2KOq8dVzXPctL SGardigyKK0qS427wMq+afaK0tjIVykRbbdwRiGn6Zxj9m4Q3VnItRKqqdDspMxi U0aNdCXXR80Ou+gJ8ap/2z1haofH8g4lvTWlHW2JRoYGibBCDLJMCDKlNDDXsRUO KAHQ+OMWloZMwHX3yskJieDWmTKuZURF2A6o0rS91KRdyIIjPZ+WEFE9LCRhE4kW opVi6n16Thu4pR5O5+x/UXITSklThqO4qsp9jOuB8F7LpSyD5OilFtWucIFqOaB5 dXWSdZSI7hbC9fZfnplBSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1767888297; x= 1767974697; bh=VcRgVy/GzIH64VlQ57dTOXDnYIRcVGkKFnjM+UXx0dY=; b=k mv3TY40ghkZZ4lqqUbGwqToTsAbyxY78WXiJKdUH1wJZpKiHevTOcjBsmKuKWArO DvQdyepuABa29TGLIlkg/CxhJ/JuVIg2XxALoGlaqZR1o8sr/wsgjqgEuHxd6nWC 1KNA0POXc58TxFnJziuZEDr5GSR0yLlJYkZkjFDaM4xED0+PAEy3OnLUwHPpbqeE FPNL5aDlGI3O5wdQAmvKTT2IvV9jSjloGjhFWGm/NOpLHYqhVKZxwx8uf2Vte1cb y/mWcbwNRPhE9peD/O0QyR4q0f14nA4w6XwhZWS/gz0EqUC5v3PhuLAXy5Ci3QHp pTGwv6yi0elxrcRdBuHLw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutdeifeelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeetughrihgr nhcumfhlrghvvghruceorggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomh eqnecuggftrfgrthhtvghrnhepgffgfedtgffggeduveduhfdukeefueefledttdetfedt udeuheeikeefveeiveejnecuffhomhgrihhnpehmvgguihhumhdrtghomhdpphhoshhtgh hrvghsqhhlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheprggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhdpnhgspg hrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepghhrihhhrggu sehgmhgrihhlrdgtohhmpdhrtghpthhtohepugguvghvihgvnhhnvgesghhmrghilhdrtg homhdprhgtphhtthhopehpghhsqhhlqdhgvghnvghrrghlsehpohhsthhgrhgvshhqlhdr ohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 8 Jan 2026 11:04:57 -0500 (EST) Message-ID: Date: Thu, 8 Jan 2026 08:04:56 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Collation again here To: Rihad , Dominique Devienne Cc: pgsql-general General References: <200eccb1-188e-49ee-9360-c3a7acb19c2c@gmail.com> <9f5996c1-abab-40da-8dd5-d56f483b22b1@gmail.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: <9f5996c1-abab-40da-8dd5-d56f483b22b1@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 1/8/26 05:18, Rihad wrote: > On 1/8/26 4:48 PM, Dominique Devienne wrote: > > Looking into pg_collation system table that collation has > collprovide="c". First I thought "c" meant libc, but this article states > that "c" means PG Internal provider, and libc would have been "l". > > https://medium.com/@adarsh2801/understanding-collations-in- > postgresql-648e4fa333e1 > > 1. */PostgreSQL Internal Provider (‘c’) /*: Introduced in Postgres 15. > This built-in collation support is System/OS agnostic. > 2. */System Library Provider (‘l’) : /*Uses GNU C library and hence is > OS locale dependent. > 3. */ICU — International Components for Unicode (‘i’) : /*Uses ICU > library for unicode-aware collation. This is what the docs are for: https://www.postgresql.org/docs/current/catalog-pg-collation.html "collprovider char Provider of the collation: d = database default, b = builtin, c = libc, i = icu " And https://www.postgresql.org/docs/current/locale.html#LOCALE-PROVIDERS " 23.1.4. Locale Providers A locale provider specifies which library defines the locale behavior for collations and character classifications. The commands and tools that select the locale settings, as described above, each have an option to select the locale provider. Here is an example to initialize a database cluster using the ICU provider: initdb --locale-provider=icu --icu-locale=en See the description of the respective commands and programs for details. Note that you can mix locale providers at different granularities, for example use libc by default for the cluster but have one database that uses the icu provider, and then have collation objects using either provider within those databases. Regardless of the locale provider, the operating system is still used to provide some locale-aware behavior, such as messages (see lc_messages). The available locale providers are listed below: builtin The builtin provider uses built-in operations. Only the C, C.UTF-8, and PG_UNICODE_FAST locales are supported for this provider. The C locale behavior is identical to the C locale in the libc provider. When using this locale, the behavior may depend on the database encoding. The C.UTF-8 locale is available only for when the database encoding is UTF-8, and the behavior is based on Unicode. The collation uses the code point values only. The regular expression character classes are based on the "POSIX Compatible" semantics, and the case mapping is the "simple" variant. The PG_UNICODE_FAST locale is available only when the database encoding is UTF-8, and the behavior is based on Unicode. The collation uses the code point values only. The regular expression character classes are based on the "Standard" semantics, and the case mapping is the "full" variant. icu The icu provider uses the external ICU library. PostgreSQL must have been configured with support. ICU provides collation and character classification behavior that is independent of the operating system and database encoding, which is preferable if you expect to transition to other platforms without any change in results. LC_COLLATE and LC_CTYPE can be set independently of the ICU locale. Note For the ICU provider, results may depend on the version of the ICU library used, as it is updated to reflect changes in natural language over time. libc The libc provider uses the operating system's C library. The collation and character classification behavior is controlled by the settings LC_COLLATE and LC_CTYPE, so they cannot be set independently. Note The same locale name may have different behavior on different platforms when using the libc provider. " Rather then some made up gibberish. > > > We only have "i" & "c" in pg_collation. And we aren't using any of "i" > it seems. All this locale/encoding/collate stuff is too much for me to > handle, sorry) > > So if we are using the internal (builtin) "c" provider how come the PG > 18.1 run on FreeBSD 13.5 version shows warnings that the system version > is 34.0? > > The article must be wrong I guess. > > Then upgrading 13.5 to 14.3 is our only option. > -- Adrian Klaver adrian.klaver@aklaver.com