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()  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: [PATCH] Add support function for containment operators
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_basebackup check vs Windows file path limits