Re: check_strxfrm_bug()
От | Peter Eisentraut |
---|---|
Тема | Re: check_strxfrm_bug() |
Дата | |
Msg-id | 1fc49e19-6989-527f-6a11-fde373d9cf22@eisentraut.org обсуждение исходный текст |
Ответ на | Re: check_strxfrm_bug() (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: check_strxfrm_bug()
|
Список | 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 по дате отправления: