Re: Thread-unsafe coding in ecpg - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Thread-unsafe coding in ecpg
Date
Msg-id 87sgxo5dp3.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
Responses Re: Thread-unsafe coding in ecpg  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Michael" == Michael Meskes <meskes@postgresql.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)


pgsql-hackers by date:

Previous
From: Donald Dong
Date:
Subject: Re: Ryu floating point output patch
Next
From: Tom Lane
Date:
Subject: Re: Changing SQL Inlining Behaviour (or...?)