Re: Thread-unsafe coding in ecpg

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)

In response to

Responses

Browse pgsql-hackers by date

  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