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
>
