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(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>

> Hi,
>
> "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>