Re: check_strxfrm_bug()

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Tristan Partin <tristan(at)neon(dot)tech>, 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-10 02:51:37
Message-ID: CA+hUKG+t_CHPzEoPnKyARJBJgE9-GxNajJo6ZuSfRK_KWFO+6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 9, 2023 at 6:35 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Sun, Jul 9, 2023 at 6:20 PM Peter Eisentraut <peter(at)eisentraut(dot)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.

Attachment Content-Type Size
0001-Don-t-expose-Windows-mbstowcs_l-and-wcstombs_l.patch text/x-patch 2.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Lepikhov 2023-07-10 03:12:23 Re: POC, WIP: OR-clause support for indexes
Previous Message Hayato Kuroda (Fujitsu) 2023-07-10 02:37:30 RE: [PATCH] Reuse Workers and Replication Slots during Logical Replication