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 1r3Oyo-003avB-Cw for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Nov 2023 23:07:30 +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 1r3Oxo-003Ooj-Bq for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Nov 2023 23:06:28 +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.94.2) (envelope-from ) id 1r3Oxo-003OoX-1y for pgsql-hackers@lists.postgresql.org; Wed, 15 Nov 2023 23:06:28 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r3Oxl-005lYp-Ay for pgsql-hackers@postgresql.org; Wed, 15 Nov 2023 23:06:26 +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 3AFN6MqH098825; Wed, 15 Nov 2023 18:06:22 -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> Comments: In-reply-to Thomas Munro message dated "Thu, 16 Nov 2023 11:40:07 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98823.1700089582.1@sss.pgh.pa.us> Date: Wed, 15 Nov 2023 18:06:22 -0500 Message-ID: <98824.1700089582@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > Idea #1 > For output, which happens with sprintf(ptr, "%.15g%s", ...) in > execute.c, perhaps we could use our in-tree Ryu routine instead? > For input, which happens with strtod() in data.c, rats, we don't have > a parser and I understand that it is not for the faint of heart Yeah. Getting rid of ecpg's use of uselocale() would certainly be nice, but I'm not ready to add our own implementation of strtod() to get there. > Idea #2 > Perhaps we could use snprintf_l() and strtod_l() where available. > They're not standard, but they are obvious extensions that NetBSD and > Windows have, and those are the two systems for which we are doing > grotty things in that code. Oooh, shiny. I do not see any man page for strtod_l, but I do see that it's declared on mamba's host. I wonder how long they've had it? The man page for snprintf_l appears to be quite ancient, so we could hope that strtod_l is available on all versions anyone cares about. > That would amount to extending > pg_locale.c's philosophy: either you must have uselocale(), or the > full set of _l() functions (that POSIX failed to standardise, dunno > what the history is behind that, seems weird). Yeah. I'd say the _l functions should be preferred over uselocale() if available, but sadly they're not there on common systems. (It looks like glibc has strtod_l but not snprintf_l, which is odd.) regards, tom lane