From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Thread-unsafe coding in ecpg |
Date: | 2019-01-20 01:32:50 |
Message-ID: | 87sgxo5dp3.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Michael" == Michael Meskes <meskes(at)postgresql(dot)org> writes:
>> Therefore, it's plain crazy for ecpg to be calling setlocale()
>> inside threaded code. It looks to me like what ecpg is doing is
>> trying to defend itself against non-C LC_NUMERIC settings, which is
>> laudable, but this implementation of that is totally unsafe.
>>
>> Don't know what's the best way out of this. The simplest thing would
>> be to just remove that code and document that you'd better run ecpg
>> in LC_NUMERIC locale, but it'd be nice if we could do better.
Would it help if we had non-locale-aware functions for both
floating-point output _and_ input? i.e. import a known-working strtod()
(allowing us to remove all the hacks that have grown up around it, for
special-case input and wonky error handling) with locale functionality
removed.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-01-20 01:53:55 | Re: Changing SQL Inlining Behaviour (or...?) |
Previous Message | Donald Dong | 2019-01-20 01:20:00 | Re: Ryu floating point output patch |