Re: On non-Windows, hard depend on uselocale(3)
От | Peter Eisentraut |
---|---|
Тема | Re: On non-Windows, hard depend on uselocale(3) |
Дата | |
Msg-id | 2652c576-29b3-4b4a-b61b-10275cacadcb@eisentraut.org обсуждение исходный текст |
Ответ на | On non-Windows, hard depend on uselocale(3) ("Tristan Partin" <tristan@neon.tech>) |
Список | pgsql-hackers |
On 20.11.24 10:00, Thomas Munro wrote: > On Fri, Nov 15, 2024 at 1:53 AM Peter Eisentraut <peter@eisentraut.org> wrote: >> On 14.11.24 08:48, Thomas Munro wrote: >>> The three MinGW environments we test today are using ucrt, and >>> configure detects the symbol on all. Namely: fairwren >>> (msys2/mingw64), the CI mingw64 task and the mingw cross-build that >>> runs on Linux in the CI CompilerWarnings task. As far as I know these >>> are the reasons for, and mechanism by which, we keep MinGW support >>> working. We have no policy requiring arbitrary old MinGW systems >>> work, and we wouldn't know anyway. >> >> Right. So I think we could unwind this in steps. First, remove the >> configure test for _configthreadlocale() and all the associated #ifdefs >> in the existing ecpg code. This seems totally safe, it would just leave >> behind MinGW older than 2016 and MSVC older than 2015, the latter of >> which is already the current threshold. >> >> Then the question whether we want to re-enable the error checking on >> _configthreadlocale() that was reverted by 2cf91ccb, or at least >> something similar. This should also be okay based on your description >> of the different Windows runtimes. I think it would also be good to do >> this to make sure this works before we employ _configthreadlocale() in >> higher-stakes situations. >> >> I suggest doing these two steps as separate patches, so this doesn't get >> confused between the various thread-related threads that want to >> variously add or remove uses of this function. > > OK, do you think these three patches tell the _configthreadlocale() > story properly? (Then after that we can get back to getting rid of > it...) Yes, this is very clear and helpful. Thanks.
В списке pgsql-hackers по дате отправления: