From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Thread-unsafe coding in ecpg |
Date: | 2019-01-20 00:37:29 |
Message-ID: | 24002.1547944649@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Meskes <meskes(at)postgresql(dot)org> writes:
>> While (b) has more theoretical purity, I'm inclined to think it
>> doesn't really improve anybody's life compared to (a), because
>> --disable-thread-safety doesn't actually stop anyone from using
>> libpq or ecpglib in threaded environments. It just makes it
>> more likely to fail when they do.
> The question is, what do we do on those platforms? Use setlocale() or
> fallback to (a) and document that ecpg has to run in a C locale?
No, we shouldn't use setlocale(), because it clearly is hazardous
even on platforms where it doesn't fail outright. I don't see
anything so wrong with just documenting the hazard. The situation
isn't noticeably more dangerous than simple use of the C library;
sscanf, strtod, etc are all likely to do surprising things when
LC_NUMERIC isn't C.
> We could also rewrite the parsing of numbers to not be locale
> dependent.
Perhaps, but that seems like a giant undertaking. I'm not excited
about duplicating strtod(), for instance.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Martinez | 2019-01-20 00:40:40 | [PROPOSAL] ON DELETE SET NULL (<column_list>) for Foreign Key Constraints |
Previous Message | Tom Lane | 2019-01-20 00:31:58 | Re: pg_stat_statements vs. SELECT FOR UPDATE |