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
On Mon, Nov 20, 2023 at 11:36 AM Tom Lane wrote:
> Thomas Munro writes:
> > BTW is this comment in snprintf.c true?
>
> > * 1. No locale support: the radix character is always '.' and the '
> > * (single quote) format flag is ignored.
>
> > It is in the backend but only because we nail down
Thomas Munro writes:
> BTW is this comment in snprintf.c true?
> * 1. No locale support: the radix character is always '.' and the '
> * (single quote) format flag is ignored.
> It is in the backend but only because we nail down LC_NUMERIC early
> on, not because of any property of
On Sat, Nov 18, 2023 at 11:58 AM Tom Lane wrote:
> I wrote:
> > I've not reviewed this closely, but I did try it on mamba's host.
> > It compiles and passes regression testing, but I see two warnings:
>
> > common.c: In function 'PGTYPESsprintf':
> > common.c:120:2: warning: function
Hi,
On 2023-11-17 08:57:47 +1300, Thomas Munro wrote:
> I also had a go[3] at doing it with static inlined functions, to avoid
> creating a load of new exported functions and associated function call
> overheads. It worked fine, except on Windows: I needed a global
> variable PGTYPESclocale that
I wrote:
> I've not reviewed this closely, but I did try it on mamba's host.
> It compiles and passes regression testing, but I see two warnings:
> common.c: In function 'PGTYPESsprintf':
> common.c:120:2: warning: function 'PGTYPESsprintf' might be a candidate for
> 'gnu_printf' format
Thomas Munro writes:
> On Thu, Nov 16, 2023 at 12:06 PM Tom Lane wrote:
>> Thomas Munro writes:
>>> 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
On Thu, Nov 16, 2023 at 12:06 PM Tom Lane wrote:
> Thomas Munro writes:
> > 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
> >
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
On Thu, Nov 16, 2023 at 10:17 AM Tom Lane wrote:
> Thomas Munro writes:
> > The other uses of uselocale() are in ECPG code that must
> > be falling back to the setlocale() path. In other words, isn't it the
> > case that we don't require uselocale() to compile ECPG stuff, but it'll
> > probably
Thomas Munro writes:
> Currently pg_locale.c requires systems to have *either* uselocale() or
> mbstowcs_l()/wcstombs_l(), but NetBSD satisfies the second
> requirement.
Check.
> The other uses of uselocale() are in ECPG code that must
> be falling back to the setlocale() path. In other words,
On Thu, Nov 16, 2023 at 9:51 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Nov 16, 2023 at 6:45 AM Tom Lane wrote:
> >> You would need to do some research and try to prove that that won't
> >> be a problem on any modern platform. Presumably it once was a problem,
> >> or we'd not have
Thomas Munro writes:
> On Thu, Nov 16, 2023 at 6:45 AM Tom Lane wrote:
>> You would need to do some research and try to prove that that won't
>> be a problem on any modern platform. Presumably it once was a problem,
>> or we'd not have bothered with a configure check.
> According to data I
On Thu, Nov 16, 2023 at 7:42 AM Dagfinn Ilmari Mannsåker
wrote:
> Tom Lane writes:
>
> > "Tristan Partin" writes:
> >> I would like to propose removing HAVE_USELOCALE, and just have WIN32,
> >> which means that Postgres would require uselocale(3) on anything that
> >> isn't WIN32.
> >
> > You
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>> "Tristan Partin" writes:
>>> I would like to propose removing HAVE_USELOCALE, and just have WIN32,
>>> which means that Postgres would require uselocale(3) on anything that
>>> isn't WIN32.
>> You would need to do some
Tom Lane writes:
> "Tristan Partin" writes:
>> I would like to propose removing HAVE_USELOCALE, and just have WIN32,
>> which means that Postgres would require uselocale(3) on anything that
>> isn't WIN32.
>
> You would need to do some research and try to prove that that won't
> be a problem
On Thu, Nov 16, 2023 at 6:45 AM Tom Lane wrote:
> "Tristan Partin" writes:
> > I would like to propose removing HAVE_USELOCALE, and just have WIN32,
> > which means that Postgres would require uselocale(3) on anything that
> > isn't WIN32.
>
> You would need to do some research and try to prove
"Tristan Partin" writes:
> I would like to propose removing HAVE_USELOCALE, and just have WIN32,
> which means that Postgres would require uselocale(3) on anything that
> isn't WIN32.
You would need to do some research and try to prove that that won't
be a problem on any modern platform.
I have been working on adding using thread-safe locale APIs within
Postgres where appropriate[0]. The patch that I originally submitted
crashed during initdb (whoops!), so I worked on fixing the crash, which
led me to having to touch some code in chklocale.c, which became
a frustrating
19 matches
Mail list logo
