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 1vTkP3-009pyb-13 for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Dec 2025 17:24:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vTkP2-004dJQ-0q for pgsql-hackers@arkaria.postgresql.org; Thu, 11 Dec 2025 17:24:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTkP1-004dJI-37 for pgsql-hackers@lists.postgresql.org; Thu, 11 Dec 2025 17:24:32 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vTkP0-000CZF-0f for pgsql-hackers@lists.postgresql.org; Thu, 11 Dec 2025 17:24:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5BBHOQVZ842388; Thu, 11 Dec 2025 12:24:26 -0500 From: Tom Lane To: Peter Eisentraut cc: pgsql-hackers@lists.postgresql.org Subject: Re: Solaris versus our NLS files In-reply-to: <9e77ce39-34e5-47c5-8f62-aeb6669df4ff@eisentraut.org> References: <292844.1765315339@sss.pgh.pa.us> <638279.1765383282@sss.pgh.pa.us> <9e77ce39-34e5-47c5-8f62-aeb6669df4ff@eisentraut.org> Comments: In-reply-to Peter Eisentraut message dated "Thu, 11 Dec 2025 15:50:47 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <842386.1765473866.1@sss.pgh.pa.us> Date: Thu, 11 Dec 2025 12:24:26 -0500 Message-ID: <842387.1765473866@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > On 10.12.25 17:14, Tom Lane wrote: >> Yeah, I've been wrestling with that question. The best idea >> I have at the moment is to look at "locale -a" output to see >> which country codes Solaris thinks there are for each language, >> and duplicate that. > I wonder how other gettext-using projects handle this on Solaris. Most > of those will use a higher-level build system such as Automake or Meson, > and I don't see any facilities there to expand languages into full > locale names on installation. So either this is broken for everyone > else, too, or perhaps this is typically addressed on the packaging level > (or there is some other explanation we're not seeing yet). In either > case, I doubt that fixing this locally in PostgreSQL is the most > appropriate solution. I suspect that the answer for most non-Solaris-specific projects has been "use GNU gettext". I don't want to rely on that answer, though, because it will break every one of our Solaris/illumos buildfarm animals, all of which are linking to libc gettext: checking for library containing bind_textdomain_codeset... none required Now it does appear that they all have (portions of?) GNU gettext installed: checking for msgfmt... /usr/gnu/bin/msgfmt and so does my OpenIndiana image, which apparently means that GNU gettext is pulled in by "sudo pkg install build-essential", because that's all I did to install stuff. So maybe we should just say we don't support the libc flavor of gettext on that platform, which would require figuring out how to force linking to libintl instead. I can look into that if it seems like a more acceptable solution. I'm worried though that it amounts to adding a new dependency on that platform. regards, tom lane