Re: check_strxfrm_bug()
От | Thomas Munro |
---|---|
Тема | Re: check_strxfrm_bug() |
Дата | |
Msg-id | CA+hUKGL=ZWwn-_cGVvCOQz+hWXaT7kvypDW=Q-kWLHyk9TPyRg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: check_strxfrm_bug() ("Tristan Partin" <tristan@neon.tech>) |
Ответы |
Re: check_strxfrm_bug()
Re: check_strxfrm_bug() |
Список | pgsql-hackers |
On Tue, Jul 4, 2023 at 2:52 AM Tristan Partin <tristan@neon.tech> wrote: > The patch looks good to me as well. Happy to rebase my other patch on > this one. Thanks. Here is a slightly tidier version. It passes on CI[1] including the optional extra MinGW64/Meson task, and the MinGW64/autoconf configure+build that is in the SanityCheck task. There are two questions I'm hoping to get feedback on: (1) I believe that defining HAVE_MBSTOWCS_L etc in win32_port.h is the best idea because that is also where we define mbstowcs_l() etc. Does that make sense? (2) IIRC, ye olde Solution.pm system might break if I were to completely remove HAVE_MBSTOWCS_L and HAVE_WCSTOMBS_L from Solution.pm (there must be a check somewhere that compares it with pg_config.h.in or something like that), but it would also break if I defined them as 1 there (macro redefinition). Will undef in Solution.pm be acceptable (ie define nothing to avoid redefinition, but side-step the sanity check)? It's a bit of a kludge, but IIRC we're dropping that 3rd build system in 17 so maybe that's OK? (Not tested as I don't have Windows and CI doesn't test Solution.pm, so I'd be grateful if someone who has Windows/Solution.pm setup could try this.) [1] https://cirrus-ci.com/build/5298278007308288
Вложения
В списке pgsql-hackers по дате отправления: