Re: Thread-unsafe coding in ecpg

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Thread-unsafe coding in ecpg
Дата
Msg-id 24002.1547944649@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
Ответы Re: Thread-unsafe coding in ecpg  (Michael Meskes <meskes@postgresql.org>)
Список pgsql-hackers
Michael Meskes <meskes@postgresql.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_stat_statements vs. SELECT FOR UPDATE
Следующее
От: Paul Martinez
Дата:
Сообщение: [PROPOSAL] ON DELETE SET NULL () for Foreign Key Constraints