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

From: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Solution of the file name problem of copy on windows.
Date: 2009-04-14 00:51:54
Message-ID: 20090414093452.91E3.52131E4D@oss.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> > Here is a patch to implement GetPlatformEncoding() and convert absolute
> > file paths from database encoding to platform encoding.
>
> This seems like a fairly significant overhead added to solve a really
> minor problem (if it's not minor why has it never come up before?).

It's not always a minor problem in Japan. It has been discussed in
users group in Japan several times. However, surely I should pay attention
to the performance. One of the solutions might be to cache the encoding
in GetPlatformEncoding(). There will be no overheads when database
encoding and platform encoding are same, that would be a typical use.

> It should not be necessary to repeat all
> this for every file access within the database directory.

That's why I added checking with is_absolute_path() there. We can
avoid conversion in normal file access under PGDATA because relative
paths are used for it. But I should have checked all of file access
not only in backends but also in client programs. I'll research them...

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-14 00:57:07 Re: [GENERAL] Fragments in tsearch2 headline
Previous Message Greg Sabino Mullane 2009-04-13 23:46:32 Re: psql with "Function Type" in \df