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.94.2) (envelope-from ) id 1r57KM-00BsQw-Uq for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Nov 2023 16:40:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r57KL-009Fpr-93 for pgsql-hackers@arkaria.postgresql.org; Mon, 20 Nov 2023 16:40:49 +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.94.2) (envelope-from ) id 1r57KK-009Fpj-Vh for pgsql-hackers@lists.postgresql.org; Mon, 20 Nov 2023 16:40:48 +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.94.2) (envelope-from ) id 1r57KI-007SaC-Le for pgsql-hackers@postgresql.org; Mon, 20 Nov 2023 16:40:48 +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 3AKGehP51330179; Mon, 20 Nov 2023 11:40:44 -0500 From: Tom Lane To: Thomas Munro cc: Tristan Partin , pgsql-hackers Subject: Re: On non-Windows, hard depend on uselocale(3) In-reply-to: References: <2689177.1700070346@sss.pgh.pa.us> <2946058.1700081498@sss.pgh.pa.us> <12842.1700083028@sss.pgh.pa.us> <98824.1700089582@sss.pgh.pa.us> <664255.1700245108@sss.pgh.pa.us> <810814.1700261928@sss.pgh.pa.us> <1155474.1700433384@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Mon, 20 Nov 2023 13:00:11 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1330177.1700498443.1@sss.pgh.pa.us> Date: Mon, 20 Nov 2023 11:40:43 -0500 Message-ID: <1330178.1700498443@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > If we are sure that we'll *never* want locale-aware printf-family > functions (ie we *always* want "C" locale), then in the thought > experiment above where I suggested we supply replacement _l() > functions, we could just skip that for the printf family, but make > that above comment actually true. Perhaps with Ryu, but otherwise by > punting to libc _l() or uselocale() save/restore. It is pretty annoying that we've got that shiny Ryu code and can't use it here. From memory, we did look into that and concluded that Ryu wasn't amenable to providing "exactly this many digits" as is required by most variants of printf's conversion specs. But maybe somebody should go try harder. (Worst case, you could do rounding off by hand on the produced digit string, but that's ugly...) regards, tom lane