| 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: | Whole Thread | Raw Message | 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 |