Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Re: Windows UTF8 system locale

Поиск
Список
Период
Сортировка
От Vladlen Popolitov
Тема Re: Windows UTF8 system locale
Дата
Msg-id fdea228bb6cad21147b705d8340cfc2f@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Windows UTF8 system locale  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
Noah Misch писал(а) 2024-12-17 02:16:
> I wasn't ready to believe it, but 010_dump_connstr indeed fails with
> GetACP()==932.  We've had test coverage of this for 8+ years, so I 
> gather few
> or no runs of the TAP suite on GetACP()==932 systems have ever 
> happened.  Wow.
> 
> Here's how your particular example traverses the CP932 command line:
> 
> CreateProcessA(0xe6 0x96 0x87 0xe5 0xad 0x97 0xe5 0x8c 0x96 0xe3 0x81 
> 0x91)
> argv[1] = e6 96 81 45 ad 97 e5 8c 96 e3 81
> GetCommandLineA() = 61 20 e6 96 81 45 ad 97 e5 8c 96 e3 81
> GetCommandLineW() = 61 20 8b41 30fb ff6d 601c 55a7 7e3a
> 
>> It's a shame the implicit conversion here doesn't fail with EILSEQ.  I
>> can't imagine how anything good can ever have come from lossy,
>> non-error-raising implicit conversions anywhere near argv[].  On the
> 
> It's a shame.

I also found that 010_dump_connstr fails, if Windows has UTF-8 option on 
(in language setting,
mentioned as beta feature in option description).

It looks like this test does not consider language settings. It creates 
user with a long name,
language settings can increase this name by 2 times in UTF-8 case,
Postgres cut this name to 64 bytes, but the test continues to use 
original long name and fails.
It is not clear, what exactly the test checks, if it fails before the 
dump check.

-- 
Best regards,

Vladlen Popolitov.



В списке pgsql-hackers по дате отправления: