Bug with PATHs having non-ASCII characters

Поиск
Список
Период
Сортировка
От Chuck McDevitt
Тема Bug with PATHs having non-ASCII characters
Дата
Msg-id 2106D8DC89010842BABA5CD03FEA406101371B1DAC@EXVMBX018-10.exch018.msoutlookonline.net
обсуждение исходный текст
Ответ на Re: Type modifiers for DOMAIN  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Bug with PATHs having non-ASCII characters  (Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>)
Re: Bug with PATHs having non-ASCII characters  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Just an FYI regarding this bug:

http://archives.postgresql.org/pgsql-bugs/2009-12/msg00267.php

Windows always uses UNICODE to store file and directory names.

The wide-char version of any WIN32 API call will accept or return data in UTF-16 encoded Unicode, regardless of the
localenvironment's single-byte (MBCS) encoding settings (codepage). 

So in the windows environment, at least, you can always be sure how to handle file/directory/path that includes
non-ASCIIcharacters. 

It's a little bit of a pain to use the wide-char API calls from PostgreSQL, but converting UTF-16 from and to UTF-8 is
prettyeasy and a guaranteed 1:1 mapping. 

P.s. The non-wide-char version of the Win32 API is just a bunch of wrappers that convert the char data to/from UTF-16
basedon the current codepage.  The wide-char API is the native one. 
To force the call to the wide-char API version, you just add W to the end of the function name (adding A forces it the
otherway). 



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: unresolved bugs
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Testing with concurrent sessions