Re: check_strxfrm_bug() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: check_strxfrm_bug()
Date
Msg-id 1fc49e19-6989-527f-6a11-fde373d9cf22@eisentraut.org
Whole thread Raw
In response to Re: check_strxfrm_bug()  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: check_strxfrm_bug()
List pgsql-hackers
On 10.07.23 04:51, Thomas Munro wrote:
> On Sun, Jul 9, 2023 at 6:35 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Sun, Jul 9, 2023 at 6:20 PM Peter Eisentraut <peter@eisentraut.org> wrote:
>>> So I don't think this code is correct.  AFAICT, there is nothing right
>>> now that can possibly define HAVE_MBSTOWCS_L on Windows/MSVC.  Was that
>>> the intention?
>>
>> Yes, that was my intention.  Windows actually doesn't have them.
> 
> Thinking about that some more...  Its _XXX implementations don't deal
> with UTF-8 the way Unix-based developers would expect, and are
> therefore just portability hazards, aren't they?  What would we gain
> by restoring the advertisement that they are available?  Perhaps we
> should go the other way completely and remove the relevant #defines
> from win32_port.h, and fully confine knowledge of them to pg_locale.c?
>   It knows how to deal with that.  Here is a patch trying this idea
> out, with as slightly longer explanation.

This looks sensible to me.

If we ever need mbstowcs_l() etc. outside of pg_locale.c, then the 
proper way would be to make a mbstowcs_l.c file in src/port/.

But I like your approach for now because it moves us more firmly into 
the direction of having it contained in pg_locale.c, instead of having 
some knowledge global and some local.




pgsql-hackers by date:

Previous
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Next
From: Melih Mutlu
Date:
Subject: Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication