Re: Solution of the file name problem of copy on windows.
От | Itagaki Takahiro |
---|---|
Тема | Re: Solution of the file name problem of copy on windows. |
Дата | |
Msg-id | 20090408105426.8FBC.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Solution of the file name problem of copy on windows. ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
Ответы |
Re: Solution of the file name problem of copy on windows.
|
Список | pgsql-hackers |
Hi, "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> wrote: > At this time, a copy file name is UTF-8. It was troubled by handling.:-( > Then, I make this proposal patch. I think the problem is not only in Windows but also in all platforms where the database encoding doesn't match their OS's encoding. Instead of Windows specific codes, how about adding GetPlatformEncoding() and convert all of *absolute* paths? It would be performed at the lowest API layer; i.e, BasicOpenFile(). Standard database file accesses with RelFileNode are not affected because is uses *relative* paths. There are some issues: * Is it possible to determine the platform encoding? * The above cannot handle non-ascii pathunder $PGDATA. Is it acceptable? * In Windows, the native encoding is UTF-16, but we will use SJIS if we takeon the above method. Is the limitation acceptable? Comments welcome. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: