Re: Solution of the file name problem of copy on windows. - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: Solution of the file name problem of copy on windows.
Date
Msg-id 20090414093452.91E3.52131E4D@oss.ntt.co.jp
Whole thread Raw
In response to Re: Solution of the file name problem of copy on windows.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.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




pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: psql with "Function Type" in \df
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Fragments in tsearch2 headline