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.takah...@oss.ntt.co.jp>
Hi,
"Hiroshi Saito" <z-sa...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
