Re: Solution of the file name problem of copy on windows.

Hi Itagaki-san.

Um,  I had a focus in help the problem which is not avoided. 
I am not sensitive to a problem being avoided depending on usage. 
However, I will wish to work spontaneously, when it is help much. 

Regards,
Hiroshi Saito

----- Original Message ----- 
From: "Itagaki Takahiro" <itagaki.takahiro@oss.ntt.co.jp>


> 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 path under $PGDATA.
>      Is it acceptable?
>    * In Windows, the native encoding is UTF-16, but we will use SJIS
>      if we take on the above method. Is the limitation acceptable?
> 
> Comments welcome.
> 
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
> 
> 
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>