From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tristan Partin <tristan(at)neon(dot)tech> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: check_strxfrm_bug() |
Date: | 2023-07-06 16:20:26 |
Message-ID: | 69795b94-7add-83d4-8264-1e5a23345709@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05.07.23 00:15, Thomas Munro wrote:
> On Tue, Jul 4, 2023 at 2:52 AM Tristan Partin <tristan(at)neon(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-07-06 16:38:03 | Re: pg_basebackup check vs Windows file path limits |
Previous Message | Laurenz Albe | 2023-07-06 16:15:56 | Re: [PATCH] Add support function for containment operators |