Re: check_strxfrm_bug()
От | Peter Eisentraut |
---|---|
Тема | Re: check_strxfrm_bug() |
Дата | |
Msg-id | 69795b94-7add-83d4-8264-1e5a23345709@eisentraut.org обсуждение исходный текст |
Ответ на | Re: check_strxfrm_bug() (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: check_strxfrm_bug()
|
Список | pgsql-hackers |
On 05.07.23 00:15, Thomas Munro wrote: > 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). I think the correct solution is to set HAVE_MBSTOWCS_L in Solution.pm. Compare HAVE_FSEEKO, which is set in Solution.pm with fseeko being defined in win32_port.h.
В списке pgsql-hackers по дате отправления: